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

[Xiaodi Wu]

On Mon, Jul 31, 2017 at 3:39 AM, Félix Cloutier <felixcloutier at icloud.com>
wrote:

>
> Le 31 juil. 2017 à 00:40, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> a écrit :
>
>
> On Mon, Jul 31, 2017 at 02:15 Gor Gyolchanyan via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> > On Jul 31, 2017, at 7:10 AM, John McCall via swift-evolution <
>> swift-evolution at swift.org> wrote:
>> >
>> >> On Jul 30, 2017, at 11:43 PM, Daryle Walker <darylew at mac.com> wrote:
>> >> The parameters for a fixed-size array type determine the type's
>> size/stride, so how could the bounds not be needed during compile-time? The
>> compiler can't layout objects otherwise.
>> >
>> > Swift is not C; it is perfectly capable of laying out objects at run
>> time.  It already has to do that for generic types and types with resilient
>> members.  That does, of course, have performance consequences, and those
>> performance consequences might be unacceptable to you; but the fact that we
>> can handle it means that we don't ultimately require a semantic concept of
>> a constant expression, except inasmuch as we want to allow users to
>> explicitly request guarantees about static layout.
>>
>> Doesn't this defeat the purpose of generic value parameters? We might as
>> well use a regular parameter if there's no compile-time evaluation
>> involved. In that case, fixed-sized arrays will be useless, because they'll
>> be normal arrays with resizing disabled.
>
>
> OTOH, if the compiler can prove that a local array is never resized, why
> *shouldn't* it get all the benefits of a fixed-sized array without having
> to use a special syntax? Put another way, why shouldn't fixed-size be one
> of those optional attributes for arrays, like ownership will be for
> variables, that users can opt into for more performance but is otherwise
> automatically worked out by the compiler?
>
>
> The optimization is defeated as soon as the storage buffer might escape,
> just like for closures. Consider this:
>
> func foo(arr: [Int])
>
> var array = [1, 2, 3, 4]
> foo(arr: array)
> array[1] = 2
>
>
> If `array` is "unrolled" to the stack, and `foo` keeps a reference to the
> storage, then `array[1] = 2` has to pessimistically create a new storage
> buffer to maintain COW semantics. It could also leave a dangling reference
> to the buffer if the function returns before all of the other references
> are gone. I'd rather not get into @escaping arrays.
>

Sure, and hence my point: suppose now `foo` is a function in the stdlib,
and the stdlib authors have annotated the function so that it is `func
foo(arr: fixed [Int])`. Then, any user who writes `var array = ...` could
benefit from a performance boost because the compiler will not longer have
to be pessimistic about copying in order to maintain COW semantics. This is
why I made an explicit analogy to the design proposed for ownership in
Swift, where end users don't have to understand it in order to benefit from
the feature because the functions they call can give sufficiently important
hints to help the compiler avoid unnecessary copying.

I don't think that you claimed that this should be a solution to the
> fixed-size array problem, but just in case, also note that it's not. We
> can't make any [Int] layout-compatible with C fixed-size arrays because the
> length has to be encoded in the type (as it cannot be encoded in the data
> itself).
>

I don't understand this point. Can you elaborate on what you mean here? Why
does it have to be layout-compatible?


> Félix
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170731/972b1962/attachment.html>