String reboot - (1a) incidental whitespace

[Alex Buckley]

On 4/22/2019 12:16 PM, Guy Steele wrote:
>> On Apr 22, 2019, at 3:04 PM, Alex Buckley <alex.buckley at oracle.com>
>> wrote:
>>
>> Nope, I don't think multi-line string literals are an attractive
>> nuisance in any way. We should NOT deem it incorrect to refactor a
>> sequence of concatenations into a single multi-line string
>> literal.
>
> I didn’t say (or mean to imply that).  I think it’s a great thing to
> refactor concatenations into a single multi-line string literal WHEN
> IT IS DONE CORRECTLY.
>
> However, if you blindly pull out the concatenations and thereby
> introduce newlines into the string when they were not there before
> and doing so violates some contract downstream, THAT IS AN INCORRECT
> TRANSFORMATION.

Literally, yes, it's an incorrect transformation for the caller to 
perform if it violates the contract offered by the callee.

> We certainly agree that it would be a good thing if everything that
> might be downstream were in fact reasonably tolerant of newlines.

Yes.

> BUT IF YOU DON’T KNOW FOR SURE THAT WHAT IS DOWNSTREAM IS TOLERANT OF
> NEWLINES, AND YOU BLINDLY TRANSFORM A STRING CONCATENATION INTO A
> MULTI-LINE STRING LITERAL THAT INCLUDES NEWLINES WHERE THERE WERE
> NONE BEFORE, THAT IS A BAD THING.

If the callee's contract says "No newlines in the string argument to 
Customer::setName", then the caller would be doing a bad thing.

But the reason this topic is interesting(ish) is because we're dealing 
with something that the vast majority of callees never thought to specify.

(Well, maybe not "never". I browsed the Java SE API Specification to 
find a method that takes a String, and randomly clicked on something in 
JNDI -- 
https://docs.oracle.com/en/java/javase/12/docs/api/java.naming/javax/naming/Name.html#add(java.lang.String) 
-- which happens to be strict about the string passed to it, so perhaps 
someone is about to get an InvalidNameException when they try to lay out 
a long LDAP query string over multiple lines.)

> And a feature that makes it too easy to accidentally do a bad thing
> _might_ be considered an attractive nuisance, AS OPPOSED TO MY
> SCREAMING ALL-CAPS, WHICH ARE A REPULSIVE NUISANCE.

I can get 90% of the way to saying "OK, multi-line string literals 
_might_ be considered an attractive nuisance", but I can't get 100% of 
the way there because it's such a callee-centric view to take when the 
purpose of the feature is to simplify the life of the caller. If you 
crack open the door to give callees a hearing, you'll get requests to 
statically reject multi-line string literals (such as via a java.* 
annotation that programmatically indicates "not multi-line safe", or a 
java.lang.MultilineString type that's a sibling of String) and we don't 
want to go anywhere near there.

(I recall a library that took Runnable or somesuch, and fell over when 
the argument was a lambda expression; the library expected an anonymous 
inner class instance in order to do some peculiar introspection, which 
failed on the opaque object reifying a lambda expression. The library 
developer _might_ have considered lambda expressions an attractive 
nuisance for a few minutes, but who would have sympathy?)

Alex