Brian will not be surprised to hear that I agree with Guy here.

The Logger use case is the main one, IIUC, which is driving
the insertion of pass-by-name (automatic quoting as if by ()->)
into the current ST design.

If we want something like Log.note("foo = "+foo()) to auto-quote to
Log.note(() -> "foo = "+foo()) we should do it as its own avowed
language feature (akin to auto boxing and varargs) and not hide
it inside of string templates.

(Turning x to ()->x is indeed a kind of quoting, since it allows the
user access to a useful name of x without elaborating x.
If and when we add lambda cracking it will also become a way
to literally quote expression trees.  If the term auto-quoting
is off the mark, may I suggest auto-delaying or pass-by-name.)

I would be delighted if we could define string templates without
rolling in an auto-delay feature for their arguments, then later
add auto-delay of arguments (to arbitrary methods) as a proper
language feature, and then, triumphantly, cross-apply those
two features to create Logger APIs that (a) make great use of
STs, and (b) smoothly delay their operands until the Logger
has decided it really wants them.

On Oct 30, 2021, at 2:11 PM, Guy Steele 
<guy.ste...@oracle.com<mailto:guy.ste...@oracle.com>> wrote:


On Oct 30, 2021, at 1:04 PM, Brian Goetz 
<brian.go...@oracle.com<mailto:brian.go...@oracle.com>> wrote:


I think that deferred semantics could be confusing and it provides too
little benefit to justify its use.  . . .

I'd characterize these argument as "this deferral is too magic and raises too 
many questions for too little benefit; if you want deferral, do it explicitly 
with ->.

I will go a step further: the proposed deferral semantics is too _surprising_.

Joe Programmer will look at

FOO."I have \{n+1} apples in my basket and \{c.size()} elements in my 
collection."

and fully expect that the expressions `n+1` and `c.size()` will be evaluated 
right away, before any of the magic associated with that dot happens.

There are languages for which deferred evaluation is the norm, the expected way 
of doing things. Haskell is one of them. Java is NOT one of them.

Java now has a standard strategy for user-specified deferred evaluation: ->.  
So it would also be surprising to introduce another, unrelated mechanism for 
user-specified deferred evaluation without a REALLY compelling reason. (I say 
“user-specified” because there are certain other mechanisms that are built-in, 
such as the ? : operator and statements such as `if` and `while`.)

Joe Programmer would expect that if FOO wants to provide for deferred 
evaluation, it would do so by accepting lambdas, and Joe would expect to 
provide them.

—Guy


Reply via email to