As far as I can tell, currently, all arrays live on the heap. > Le 3 août 2017 à 19:03, Robert Bennett via swift-evolution > <swift-evolution@swift.org> a écrit : > > Where do constant Arrays currently live? I hope the answer is on the stack, > since their size doesn’t change. > > On Aug 3, 2017, at 8:44 PM, Taylor Swift via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> >> >> On Thu, Aug 3, 2017 at 8:20 PM, Karl Wagner via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>> >>>> The root cause, of course, is that the VLAs require new stack allocations >>>> each time, and the stack is only deallocated as one lump when the frame >>>> ends. >>> >>> That is true of alloca(), but not of VLAs. VLAs are freed when they go out >>> of scope. >>> >> >> Learned something today. >> >> Anyway, if the goal is stack allocation, I would prefer that we explored >> other ways to achieve it before jumping to a new array-type. I’m not really >> a fan of a future where [3; Double] is one type and (Double, Double, Double) >> is something else, and Array<Double> is yet another thing. >> >> They are completely different things. >> >> [3; Double] is three contiguous Doubles which may or may not live on the >> stack. >> >> (Double, Double, Double) is three Doubles bound to a single variable name, >> which the compiler can rearrange for optimal performance and may or may not >> live on the stack. >> >> Array<Double> is an vector of Doubles that can dynamically grow and always >> lives in the heap. >> >> >> From what I’ve read so far, the problem with stack-allocating some Array >> that you can pass to another function and which otherwise does not escape, >> is that the function may make an escaping reference (e.g. assigning it to an >> ivar or global, or capturing it in a closure). >> >> How about if the compiler treated every Array it receives in a function as >> being potentially stack-allocated. The first time you capture it, it will >> check and copy to the heap if necessary. All subsequent escapes (including >> passing to other functions) use the Array known to be allocated on the heap, >> avoiding further checking or copying within the function. >> >> The same goes for Dictionary, and really any arbitrary value-type with COW >> storage. The memory that those types allocate is part of the value, so it >> would be cool if we could treat it like that. >> >> >> This is not true. FSAs have nothing to do with automatic storage, their >> static size only makes them eligible to live on the stack, as tuples are >> now. The defining quality of FSAs is that they are static and contiguous. >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution