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

[Karl Wagner]

> On 4. Aug 2017, at 20:15, John McCall via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 
>> On Aug 4, 2017, at 1:19 PM, Félix Cloutier via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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? 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.

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


// Module one

import ModuleTwo

func doSomething() {

    let values = (0..<5).map { _ in random() }    // allocated inline, since the size can never change
    ModuleTwo.setGlobalItems(values)              // passes a stack-allocated array to the (opaque) function
}

// Module two

var GlobalItems = [Int]()
var MoreGlobalItems = [Int]()

func setGlobalItems(_ newItems: [Int]) {

    GlobalItems = newItems          // assignment to escaping reference: checks for inline storage, copies to heap if needed

    // all references to ‘newItems’ from this point refer to the copy known to be on the heap

    MoreGlobalItems = newItems  // we already have a known out-of-line copy of the value; no checks or copying needed
}

// To make it more explicit...

func setGlobalItems_explicit(_ newItems: [Int]) {

    let newItems_heap = newItems.backing.isAllocatedInline ? newItems(withBacking: newItems.backing.clone()) : newItems
    GlobalItems       = newItems_heap
    MoreGlobalItems   = newItems_heap
}


This would require some special language support for values that allocate memory which is managed as COW.

- Karl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170806/8c1f3fa2/attachment.html>