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
<[email protected]<mailto:[email protected]>> wrote:
On Oct 30, 2021, at 1:04 PM, Brian Goetz
<[email protected]<mailto:[email protected]>> 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
