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

Taylor Swift kelvin13ma at gmail.com
Thu Aug 3 19:44:19 CDT 2017


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170803/8aaa84f1/attachment.html>


More information about the swift-evolution mailing list