Method chain as item

[contactomorph]

Introduce method chains: a native item whose parameter list is split across named, dot-separated sections, as an additive alternative to named/optional arguments.

Important

Since RFCs involve many conversations at once that can be difficult to follow, please use review comment threads on the text changes instead of direct comments on the RFC.

If you don't have a particular section of the RFC to comment on, you can click on the "Comment on this file" button on the top-right corner of the diff, to the right of the "Viewed" checkbox. This will create a separate thread even if others have commented on the file too.

Rendered

[ds84182]

I don't understand how this is beneficial if the entire chain is required. Optionality compliments named parameters, and this lacks it entirely.

This is also quite similar to method chains in Dart. e.g. var foo = new Foo()..a()..b()..c(); which calls a, b, and c on the new instance, discards their return values, and then initializes the variable with the new instance. However Dart's version is much more versatile. A Rust equivalent would work for methods that take self by-ref and by-mut. This allows for optionality.

But Dart-like method chaining is still missing required named parameters. While this proposed feature can emulate those, it adds arbitrary restrictions to the ordering of the "method" invocations.

View changes since the review

[kennytm]

I think forcing a compilation error is not gonna work cleanly, since x.y().z() itself is a valid expression the error can't happen at parser level, so it must be enforced by typeck which the compiler need to invent some type which can only be used if directly followed by the rest of the chain. This can be partially fulfilled by making the intermediate type unsized. With the current situation of having unsized_fn_params minus unsized_locals, you'll get these behavior:

// allowed
let movie_0 = define_movie(t0).release_in(y0).directed_by(n0);

// also allowed (!)
let movie_1 = ( define_movie(t1).release_in(y1) ).directed_by(n1);

// compile error (currently an ICE)
let movie_2 = { define_movie(t2).release_in(y2) }.directed_by(n2);

// allowed, but you can't use `partial_movie_3` to do anything safe.
let partial_movie_3 = &(define_movie(t3).release_in(y3));

View changes since the review