That's not a concern with the `let` case that Robert brought up, since you can't mutate a `let` array at all.
The big thing is that unconstrained escape analysis is uncomputable. Since Swift array storage is COW, any function that receives the array as a parameter is allowed to take a reference on its storage. If the storage lives on the stack and that reference outlives the stack frame, you've got a problem. It's the same problem that motivated @escaping for closures. You could allow storage to be on the stack by forcing user to make a pessimistic copy, which is possibly not an improvement. > Le 4 août 2017 à 09:21, Taylor Swift via swift-evolution > <[email protected]> a écrit : > > No, that doesn’t work. In many cases you want to mutate the elements of the > array without changing its size. For example, a Camera struct which contains > a matrix buffer, and some of the matrices get updated on each frame that the > camera moves. The matrix buffer also stores all of the camera’s stored > properties, so what would be conceptually stored properties are actually > computed properties that get and set a Float at an offset into the buffer. Of > course this could all be avoided if we had fixed layout guarantees in the > language, and then the Camera struct could be the matrix buffer and dispense > with the getters and setters instead of managing a heap buffer. > > On Fri, Aug 4, 2017 at 11:02 AM, Robert Bennett via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > So, I’m getting into this thread kind of late, and I’ve only skimmed most of > it, but… > > A special FSA on the stack seems like the wrong direction. Wouldn’t it make > more sense to have *all* value types that don’t change in size — including > `let` Arrays — live on the stack? In which case, FSA would merely act like a > normal `let` Array, without RangeReplaceableCollection conformance, whose > elements could be changed via subscripting. I know nothing about the > underlying implementation details of Swift, so I may be way off base here. > >> On Aug 4, 2017, at 2:18 AM, David Hart <[email protected] >> <mailto:[email protected]>> wrote: >> >> Don’t small arrays live on the stack? >> >>> On 4 Aug 2017, at 06:35, Félix Cloutier via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> 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 >>>> <[email protected] <mailto:[email protected]>> 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 >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>>> >>>>> >>>>> On Thu, Aug 3, 2017 at 8:20 PM, Karl Wagner via swift-evolution >>>>> <[email protected] <mailto:[email protected]>> 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 >>>>> [email protected] <mailto:[email protected]> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> > > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
