> On 4. Aug 2017, at 02:44, Taylor Swift via swift-evolution
> <[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.
>
Yeah, I understand that — the problem I have is that I’m not sure it’s going to
be obvious to everybody else when they should use which. We need to balance
semantic purity against simplicity and ease-of-learning.
For example, I’m not sure many users are aware that tuple elements in Swift
don’t have an ordered relationship; they certainly give that impression. This
is especially confusing as "In mathematics a tuple is a finite ordered list
(sequence) of elements.” [https://en.wikipedia.org/wiki/Tuple
<https://en.wikipedia.org/wiki/Tuple>]
>
> 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.
Really, the only practical difference between a FSA and a tuple is the memory
layout. Do most users really need to care about that? For those users that do,
wouldn’t an @-attribute be a less intrusive change to the language than a whole
new list-style type?
For example, the benefit to having Collection-conforming tuples as our FSAs
would be that they don’t necessarily have to be contiguous. If you have a large
multi-dimensional list of Bools or some other tiny type, you might also benefit
from those layout optimisations.
I like the simplicity in telling people:
- If you need a dynamically-sized list, use an Array
- If you need a fixed-sized list, use a tuple (and it will get an optimised
layout. You can override this with an attribute, similar to @fixed_layout or
@inlineable).
- Karl
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
