> Le 6 août 2017 à 08:15, Karl Wagner <razie...@gmail.com> a écrit :
>
>>
>> On 4. Aug 2017, at 20:15, John McCall via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>>>
>>> On Aug 4, 2017, at 1:19 PM, Félix Cloutier via swift-evolution
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>
>>> That's not a concern with the `let` case that Robert brought up, since you
>>> can't mutate a `let` array at all.
>>>
>>> The big thing is that unconstrained escape analysis is uncomputable. Since
>>> Swift array storage is COW, any function that receives the array as a
>>> parameter is allowed to take a reference on its storage. If the storage
>>> lives on the stack and that reference outlives the stack frame, you've got
>>> a problem. It's the same problem that motivated @escaping for closures.
>>>
>>> You could allow storage to be on the stack by forcing user to make a
>>> pessimistic copy, which is possibly not an improvement.
>>
>> Right. I think maybe the name people keeping using for this feature is
>> misleading; a better name would be "inline arrays" or "directly-stored
>> arrays". Having a fixed size is a necessary condition for storing the array
>> elements directly, but the people asking for this feature are really asking
>> for the different representation, not just the ability to statically
>> constrain the size of an array.
>>
>> That representation difference comes with a lot of weaknesses and
>> trade-offs, but it's also useful sometimes.
>>
>> John.
>>
>
> Right, and the question I’ve been asking (indirectly) is: why is this only
> useful for arrays?
One special thing about fixed-size arrays is that they address the sore spot of
C interop.
> Doesn’t it really apply to any value-type which allocates storage which it
> manages with COW semantics (e.g. Dictionary, Set, Data, your own custom
> types…)? Really, we want to inform the compiler that the
> dynamically-allocated memory is part of the value - and if it sees that the
> storage is only allocated once, it should be allowed to allocate that storage
> inline with the value, on the stack.
Assuming that fixed-size arrays are a different type (like FixedSizeArray<T, N>
vs Array<T>), the feature work that supports them would likely be sufficient to
support fixed-size whatever collections, too. However (and I'm talking a bit
through my hat here, that's not my area of expertise), I think that there could
be some drawbacks to implementing some other collections in a fixed amount of
memory. For instance, you have to decide on a fixed number of buckets for sets
and dictionaries, regardless of what ends up in the collection. Dictionaries
and sets also tend to use more memory than arrays, which could cause storage
size to balloon up to degrees that are not immediately obvious.
> As I understand it, the only problem with this is when a function takes such
> a value as a parameter and assigns it to some escaping reference (an ivar,
> global, or capturing it inside an escaping closure).
>
> So why can’t such assignments simply check if the value has inline storage
> and copy it to the heap if necessary? The compiler should be able to optimise
> the function so the check (which is really cheap anyway) only needs to happen
> once per function. Because the entire type has value semantics, we can
> substitute the original value with the copy for the rest of the function
> (preventing further copies down the line).
The rest of the function might not be enough, especially if you use the same
array for multiple calls. See:
> var globalArray = [[Int]]
> func append(array: [Int])
> globalArray.append(array)
> }
>
> func foo() {
> let bar = [1,2,3]
> append(array: bar)
> append(array: bar)
> append(array: bar)
> }
The function that escapes the array is `append(array:)`, so you'd get one copy
per call to `append(array:)`, unless functions start annotating the escaping
behavior of each parameter. That could work in many cases, but the compiler
would still have to be pessimistic in common instances, like when calls to
virtual functions are involved, including closures and calls to methods of
objects represented as protocol instances. (Also, the amount of work required
is likely to be significant.)
Félix
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
