Accessor effect of member subscripts

[tothambrus11]

Method Bundles

We can annotate methods defined in a method bundle of a struct with sink, let, inout, (maybe set?) to define the access for the implicit self parameter (the receiver):

public type B: Deinitializable {
  public var x: Int
  public memberwise init

  public fun foo(_ n: sink Int) {
    let   { B(x: n) }
    inout { &self.x = n }
  }
}

Free subscript bundles

Free subscripts can also be declared in a bunfle, but IIUC there we indicate the access of the yielded value. In the standard library I only found let accessors in bundles, and this instance. I don't know why these cannot be in one bundle. Also, why would be there a need for yielded & what does that mean exactly?

/// Projects `value` with its memory representation reinterpreted as a value of type `U`.
public subscript unsafe_bitcast<T, U>(_ value: T): U {
  let {
    sink let p: Pointer<U> = Pointer(type_punning: pointer[to: value])
    yield p.unsafe[]
  }
  // TODO: `value` must be passed `yielded`
  // inout {
  //   sink let p: PointerToMutable<U> = PointerToMutable(type_punning: mutable_pointer[to: &value])
  //   yield &p.unsafe[]
  // }
}

/// Returns `value` with its memory representation reinterpreted as a value of type `U`.
public fun unsafe_bitcast<T, U: Movable>(consuming value: sink T) -> U {
  sink let p: PointerToMutable<U> = PointerToMutable(type_punning: mutable_pointer[to: &value])
  Builtin.mark_uninitialized(value)
  return p.unsafe_pointee()
}

Subscript bundle as a member

It's also possible to define member subscripts:

public conformance Array: Collection {
  ...
  /// Accesses the element at `position`.
  ///
  /// - Requires: `position` is in the range `0 ..< count()`.
  public subscript(_ position: Int): Element {
    let {
      precondition((position >= 0) && (position < count()), "position is out of bounds")
      yield pointer_to_element(at: position).unsafe[]
    }
    inout {
      precondition((position >= 0) && (position < count()), "position is out of bounds")
      yield &(pointer_to_element(at: position).unsafe[])
    }
  }
}

To me it seems that we ought to have both control knobs in this case: controlling whether we take self as inout/let/sink, and whether the projected value is projected as inout/let.

What is happening in the current design? What's the reason for not exposing both of these knobs? E.g. why shouldn't we have member subscripts that yield a set value but take the receiver as inout?

This might be a related discussion: https://github.com/orgs/hylo-lang/discussions/1061

[tothambrus11]

IIUC currently the variant of a member subscript bundle couples the two knobs, as if having self as an implicit yielded parameter as described in the Language Tour. The natural extension of this would be to make it possible to explicitly mention the self argument:

public conformance Array: Collection {
  ...
  public subscript(self: inout Self, _ position: Int): Element {
    let { ... }
    inout { ... }
  }
}

The obvious limitation of this is that it limits us to fixing the access variant of Self, while being able to implement variants for the different yielded value accesses. The complete model would allow us to implement a subset of the 4x4 matrix of possible variations:

public conformance Array: Collection {
  ...
  public subscript(self: inout Self, _ position: Int): Element {
    let Self, let yield { ... }
    inout Self, set yield { ... }
    set Self, set yield { ... }
    ...
  }
}

I don't know what effect would this have on the varaint selection algorithm, but I suspect it won't be happy.

[kyouko-taiga]

I will explain what the new front-end does, because I think I reached a more principled model that is also simpler to describe.

Functions and subscripts can be declared in bundles. In source syntax that is signaled by declaring the effect of the call operator to be auto:

fun f(x: let Int, y: auto Int) auto -> B { ... }

The variant that will be used when referring to a bundle depends on the way the result of the bundle is used. The decision happens in two steps:

• During type inference, we determine whether or not the result is used in a mutating position, which decides whether we'll use inout/set or let/sink
• During IR analysis, we make the final decision depending on the initialization state of the operands.

The parameters of a bundle can be declared auto, which simply means that the passing convention will match the variant being applied. For example, in the sink variant of f above, x is a let parameter and y is a sink parameter.

Nothing more sophisticated happens for members, since the effect of the call is implicitly the effect of the receiver. For example, if f was declared as a member function then its implicit self parameter would be auto.

We cannot control the two "knobs" independently because there are only so many ways we can direct inference to select a specific variant automatically.

[tothambrus11]

Thanks for the response, this makes sense.

I guess then the only reamaining question is whether it's worth adding a way to still add one-off subscript instances where we do control both knobs that is ought to be explicitly selected by the caller (e.g. such subscript would be required to have a unique name). Also, apart from accessing private members, we could emulate the behavior anyways:

subscript please_fill_my_part(inout whole: A) -> Part {
   set { 
      sink let unset_part: Part // or maybe `set`?
      yield &unset_part
      &whole.part = unset_part
   }
}

IMO it would be nice & symmetric if there was no restriction in adding this as a member subscript so it can be accessed via the . syntax, or at least allow providing private access rights to the Whole inside the subscript's body. But we can also see if all this is justified & there are legit use cases for them.

[kyouko-taiga]

If you have only one variant (as your example shows) then you don't need a bundle at all. If you have a bundle whose variants are only explicitly selected by the user then I think it's simpler to just declare two entities. The main benefit of a bundle is to have the compiler "figure out" the variant that should be used.

There are of course other benefits in terms of documentation and perhaps concision but I am not convinced there are enough use cases of variants where one has to vary the access of the projection differently than the access of the arguments to justify the complexity.

[dabrahams]

For example, in the sink variant of f above, y is a let parameter and y is a sink parameter

Surely you mean that x is a let parameter.

[kyouko-taiga]

Indeed. I fixed the typo.

[dabrahams]

One variant that cannot currently be spelled in this model is the one that produces an inout projection from a let receiver, which is believed to be important for dropping elements of a slice of immutable elements.

In fact I think it may be important for simply iterating over the elements of the slice or for that matter any immutable collection, since the iterator needs to be both bound to the lifetime of the collection and mutated.

IIUC the current workaround is to “project” the mutable thing as an inout argument to a call of a passed function. I am not sure that is ergonomically adequate, because it seems to preclude for loops, forcing us into a more functional world of forEach methods. But maybe I'm missing something.

[kyouko-taiga]

We've discussed this "non mutating" variant and while I understand the use case I am still not convinced it is worth its complexity in terms of implementation and impact on the explainability of the language. I'd like to empirically demonstrate that the higher-order function approach is impractical before we introduce this new form.

There are two kinds of for loops in Hylo, the consuming and the non-consuming ones. The distinction is expressed by the introducer that binds the loop variable. Non-consuming loops use a conformance to Collection (as opposed to Swift which always use a conformance to Sequence AFAIK) and thus they do not require this non mutating variant.