Consider implementing mutating properties and subscripts

[kyouko-taiga]

There is currently no way to declare a member subscript that mutates its receiver regardless of the variant that is used. Such a feature would be useful to implement projections of mutable pointers to the contents of a whole. For example:

extension Array {
  public property contiguous_storage inout: PointerToMutable<Element> { ... }
}

It is actually possible to emulate this feature with free subscripts, which probably reveals that we have a gap to fill:

subscript contiguous_storage<Element>(of a: inout Array<Element>): PointerToMutable<Element> { ... }

[dabrahams]

I don't understand your example. It merely shows syntax for a declaration, but it doesn't show what usage that declaration would enable. If I had to guess, it would be something like

// where `a` is mutable
let p = a.contiguous_storage

But IIUC, we will already allow that, synthesizing the let accessor from the inout one. So what are you actually trying to achieve?

[kyouko-taiga]

But IIUC, we will already allow that, synthesizing the let accessor from the inout one.

We're not synthesizing anything yet, and even if we were I'm not sure we can synthesize let from inout:

type A {
 var x = 0
  property y: Int {
    inout { var t = x; yield &t; &x = t }
  }
}

public fun main() {
  let a = A()
  let b1 = a.y // most likely wrong
  let b2 = a.y // even more wronger
  print(b1 + b2)
}

So what are you actually trying to achieve?

I'm trying to define a subscript that yields an immutable projection but is allowed to mutate its receiver, defined as a method. This is possible today:

subscript f(p: inout {x: Int, y: Int}): Int {
  let { &p.x += 1; yield p.x }
}

But this is not:

extension {x: int, y: Int} {
  property f inout: Int {
    let { &self.x += 1; yield p.x }
  }
}

[dabrahams]

Again, your declarations don't describe what you're trying to achieve (and the first one doesn't even have balanced parentheses so I don't know what it's declaring). What usage of these declarations would be legal that is not legal today?

I do see why we can't synthesize let from inout, although I don't think your example illustrates it (just saying something is “likely wrong” doesn't explain why it's wrong): inout can temporarily invalidate the source and the source can be “concurrently” read while a let projection is extant.

[kyouko-taiga]

and the first one doesn't even have balanced parentheses so I don't know what it's declaring

??

This compiles on main:

subscript f(p: inout {x: Int, y: Int}): Int {
  let { &p.0 += 1; yield p.0 }
}

What I'm trying to achieve is to project an immutable projection whose value can only be obtained by modifying an argument.

I don't know how to describe that more precisely. Perhaps a more concrete example?

type Vector<T> {
  var root: Union<Tree<T>, Array<T>>
}

subscript viewed_as_array<T>(_ x: inout Vector<T>): Array<T> {
  match x.root {
    let t: Tree<T> { let a = Array(t); yield a, &x.root = a  }
    let a: Array<T> { yield a  }
  }
}

IIRC this need came up while I was implementing Hylo's equivalent of Swift's String.withUTF8.

[dabrahams]

and the first one doesn't even have balanced parentheses so I don't know what it's declaring
??

Sorry, I don't know what's wrong with my eyes.

What I'm trying to achieve is to project an immutable projection whose value can only be obtained by modifying an argument.
I don't know how to describe that more precisely. Perhaps a more concrete example?

I'm telling you that I don't know how to understand what capability clients of such a projection would have based on just looking at the declaration. I keep saying “show me usage.” That means, not declarations, but code involving subscript syntax, like let x = y[z], that couldn't be legal without the ability to write the declaration you're proposing, with enough context to make it obvious why it wouldn't be legal. I already said, it would look something like:

// where `a` is mutable
let p = a.contiguous_storage

How could I have been more clear?

I don't know why you'd want to project an immutable array out of your mutable vector, but if I try to guess, two possibilities come to mind:

1. you want to project out of the mutable vector again while that projected array is still alive… but in that case you can't modify the vector to get the array, so you need a projection that doesn't mutate the vector, so that can't be it.
2. the projection is a widening conversion so there may be no way to put the array value back into the vector if the array is modified.

But guessing is a lot of work for both of us. I'm hoping you can just tell me what capability you're trying to expose.

In this example it seems very strange to change the representation of your Vector when the array is accessed, and the name viewed_as_array doesn't capture the semantics of that representational change at all, which makes me suspect that this isn't something we'd want to support. Also, IMO the member subscript is a different case from the free-standing one. It's very clear that f[&x].g() mutates x but not the projected value; you'd need to write &f[&x].g() to say that. &x[].g(), on the other hand, is muddled. So I'm not at all sure we should support what you seem to be driving at.

(See how looking at usage is revealing?)