Explicit partial calls.

[jemc]

Rendered.

[jemc]

This change was brought up by @sylvanc and discussed at last week's sync call, in case anyone wants to go listen to that recording for some further context as to why it's being proposed.

[SeanTAllen]

Quick reaction, I like the idea of alternative 2 the most but before I really say much of anything, I'd like to discuss more fully at a sync sometime.

[jemc]

@sylvanc is also favorable toward alternative 2 as well.

However, I had the thought that alternative 2 might screw up the syntax @Praetonus' RFC about stateful exceptions #76. So that's something to consider. @Praetonus, maybe you can comment about those effects, and what the syntax might look like for RFC #76 if we adopt alternative 2 in this RFC.

[Perelandric]

Just wanted to mention that when I did my project in Pony, not knowing which method was partial was enough of a problem that I started prefixing my partial methods with try_. This RFC will be a helpful feature.

[Praetonus]

@jemc Yeah, that might be a problem. One nice effect of the current syntax for ? is the visual similarity between an union type and an error type. For example, fun foo(): (RetType | ErrType) could become fun foo(): RetType ? ErrType with #76. If we were to implement alternative 2 in this RFC, it would leave 2 possibilities for #76.

1. Duplicate the ? symbol: fun foo?(): RetType ? ErrType. This looks really odd to me.
2. Move the error type: fun foo? ErrType(): RetType. This scatters return type information in different places of the signature, so it's bad.

Regarding this RFC itself and the two alternatives, I think leaving the ? after the return type makes more sense semantically. I'm seeing it as "you can get a ReturnType value from this function, and if we can't produce a value we'll error", i.e. almost as if the ? is part of the return type. This is a very small concern though, so my biggest concerns are on the impact that it would have on #76.

[sylvanc]

After discussing on the sync, we all found the ? coming after the arguments to be surprisingly readable. @Theodus pointed out that it might look bad with call chaining, and I agreed... but then he and I tried it, and both found that it still looks fine :)

[jemc]

@sylvanc said he was tempted to merge this as is (abandoning alternative 2), but I wanted to make sure to check with @SeanTAllen first, since he wasn't present for the call, and had expressed a preference for alternative 2.

[SeanTAllen]

@jemc i still prefer 2, but i seem to be in the minority. ¯_(ツ)_/¯. so i'm ok with it. even if its wrong. ;)

[insanitybit]

Something to consider, syntax-wise here, is that both Rust and Ruby (and perhaps others) use the ? operator and have it at the end of the function call:

foo()?.bar().baz()? for example in Rust.

It may be worth considering familiarity with the ? coming from other languages.

Also, with multi-line call chaining, the question marks in this chain stick out really nicely at the end of each line that may throw.

object.foo()?
      .bar()?
      .baz()
      .blah()?