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

[Félix Cloutier]

> 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 <mailto:swift-evolution at swift.org>> wrote:
> > On Jul 31, 2017, at 7:10 AM, John McCall via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> >
> >> On Jul 30, 2017, at 11:43 PM, Daryle Walker <darylew at mac.com <mailto: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.

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).

Félix

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170731/460ff460/attachment.html>