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 <da...@hartbit.com> wrote: > > Don’t small arrays live on the stack? > >> On 4 Aug 2017, at 06:35, Félix Cloutier via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 >>> <swift-evolution@swift.org <mailto: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 <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 <mailto: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
