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

[Taylor Swift]

On Thu, Aug 3, 2017 at 11:17 PM, Karl Wagner <razielim at gmail.com> wrote:

>
> On 4. Aug 2017, at 02:44, 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.
>
>
>
> 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]
>
>
>> 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
>

Actually, if you do a lot of graphics programming like I do, the memory
layout is very, *very* important. Swift may not care about layout, but many
APIs that it interacts with do.

Is @fixed_layout actually planned to be part of the language? I was under
the impression it’s just a placeholder attribute. Either way, I’d
appreciate not having to write Float sixteen times for a 4x4 matrix type.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170803/3f91a01b/attachment.html>