[swift-evolution] [Planning][Request] "constexpr" for Swift 5

[Taylor Swift]

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 <
swift-evolution at swift.org> 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 <david at 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 at 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 at 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 at swift.org> wrote:
>
>
>
> On Thu, Aug 3, 2017 at 8:20 PM, Karl Wagner via swift-evolution <
> swift-evolution at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170804/180405c0/attachment.html>