[Pitch #2] Lifetime dependencies for non-`Escapable` values

Evolution Pitches
34

Should we disallow copying the dependency of a inout parameter?

After reading the "Allowed Lifetime Dependencies" section of the proposal, I was pretty clear about the constraints "if the ArgType is Escapable". However, when discussing "If the ArgType is non-Escapable", the proposal simple says

in addition to borrow or & , a copy dependency-kind is allowed, to indicate that the returned value has the same dependency as the argument.

I think it left out a case where an inout scoped dependency is copied. And it is actually legal to write the following code using the nightly compiler build:

struct A: ~Escapable {
    @lifetime(immortal)
    init() {}

    mutating func mutate() {}
}

@lifetime(&a)
func create_scoped(_ a: inout A) -> A {
    return a
}

@lifetime(copy a)
func create_copy(_ a: inout A) -> A {
    return a
}

func bar() {
    var a = A()
    var b = create_scoped(&a)
    var c = create_copy(&b)

    b.mutate()
    c.mutate()
}

Here both b and c have inout dependencies on a, and they can be mutated overlappingly. Shouldn't this be an error?

[Pitch] Non-Escapable Types and Lifetime Dependency