Implicit 'this' return for void methods

Guy Steele guy.steele at
Wed Mar 26 15:51:49 UTC 2014

On Mar 26, 2014, at 4:17 AM, Ulf Zibis <Ulf.Zibis at> wrote:

> See also:
> . . .

This last one has a specific proposal, which is simple and quite nice.  The important idea is
that we don’t actually make any change to the code of void methods or make them actually
return anything; instead, the caller takes notice of situations where an invocation of
a void method is used as a subexpression whose value is required (heretofore forbidden
by the language) and gives it a special interpretation.

I note that Ulf’s proposal applies only to method invocations, but I note that the same
technique could be used to include field references if desired.

I am wholeheartedly in favor of allowing “chaining” of dotted expressions such as


I am a bit more skeptical about expressions that begin with a dot because of potential
confusion about which expression is referred to:

    myVeryLongNamedString.subString(.indexOf("C”), .indexOf("Q”))

seems clear enough, but what about:

    myVeryLongNamedString.subString(.indexOf("C”) + otherString.length(), .indexOf("Q”))

Does the second occurrence of .indexOf use myVeryLongNamedString or otherString?

A compromise would be to allow leading-dot expressions to occur only within the arguments
of the method call whose target is the object which the leading-dot expressions are expected
to use as their target, and if there are such leading-dot expressions within the arguments
then the arguments must not contain any non-leading-dot field references or method calls.
Just a thought for discussion.  This would be considered a separate mechanism from the
chaining-of-void-methods mechanism (it was a very clever idea to try to unify them in Ulf's
original proposal, though).


More information about the core-libs-dev mailing list