Issue Description:

From the discussion on https://forums.swift.org/t/the-role-of-autoreleasepool-in-swift-and-thoughts-about-memory-management-in-swift/52976:

Swift has at least the promise „when nothing is referencing your object, it will be freed“. Interpreting this as „it will be freed at any later point“ is then really not enough. In non-concurrent code I expect the object to be freed the very moment the references to it are removed. From a technical standpoint, I would not understand why this should happen at a later moment.(*) In the loop cited below, where some possibly large chunks of memory get allocated, I need to have the garantee that in the next iteration, where the old object has lost any references to it, the memory has been freed. I certainly do not want to have all those large chunks of memory accumulated, this would just not be OK. Else, I need my manual memory management back (at least at this place)(**). So if Swift does not have guarantees for freeing memory, maybe it needs them. Another place where Swift seems not to have garantees is the layout of arrays of structs, but I think many people expect a certain layout for the obvious cases. The problem with the point of view that a "higher" computer language should not be concerned with those implementation issues is that at some points, such a language then cannot be used (or you need to write "ugly" code).

Example:

for _ in 1...1000 {
let _ = try Data(contentsOf: URL(fileURLWithPath: "myFile"))
}

print("\nPRESS RETURN TO CONTINUE"); let _ = readLine()

—

(*) In Java you only have the garantee that things will be freed at some later point, but there you give an upper bound for the memory to be used by the program and the garbage collector kicks in at least when you are near that upper bound. In a situation where there is not such an upper bound (and I am happy that Swift programs do not need those upper bounds) I certainly do need other guarantees.

(**) I know you can do manual memory management in Swift (UnsafePointer etc.), but saying "OK, Swift is a nice language with this nice automatic reference counting, but at some (many?) places you then have to manage the memory manually" does not sound good to me. The promise "you can write nice code and it will be efficient" sounds much better.