Implicit 'this' return for void methods

Bruce Chapman brucechapman at
Tue Apr 1 09:28:01 UTC 2014

Slightly preceding Ulf's coin proposal by a few hours was

Where I suggested the "naked dot" notation (coined in 
has better value as ".. a
syntax for referring to the receiver of a method inside arguments to the

More formally, the naked dot  (at the start of an expression, not 
following an invocation to a void method) would refer to the receiver of 
the innermost surrounding invocation expression.

and so to answer Guy's question below in terms of my original intention 
rather than Ulf's proposal, .indexof("Q") would use 
myVeryLongNamedString as its receiver.

I see particular value for these naked dot expressions in creating 
fluent APIs such as builder patterns. As suggested in my coin post, 
there is also value for passing enums or named constants to methods when 
(as is often the case) these named constants are defined in the same 
class as the method being invoked. In a highly informal sense, the naked 
dot enables on demand changing of the scope to be that of the invocation 
expression's receiver,

I think with this interpretation of the meaning of naked or leading dot, 
Guy's compromise restriction below is not required.


On 27/03/2014 4:51 a.m., Guy Steele wrote:
> 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).
> —Guy

This email is free from viruses and malware because avast! Antivirus protection is active.

More information about the core-libs-dev mailing list