> Le 31 juil. 2017 à 00:40, Xiaodi Wu via swift-evolution > <[email protected]> a écrit : > > > On Mon, Jul 31, 2017 at 02:15 Gor Gyolchanyan via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > > On Jul 31, 2017, at 7:10 AM, John McCall via swift-evolution > > <[email protected] <mailto:[email protected]>> wrote: > > > >> On Jul 30, 2017, at 11:43 PM, Daryle Walker <[email protected] > >> <mailto:[email protected]>> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
