String reboot - (1a) incidental whitespace

[Guy Steele]

Good points.  Like I said, I think we are in agreement!  —Guy

> On Apr 22, 2019, at 8:00 PM, Alex Buckley <alex.buckley at oracle.com> wrote:
> 
> 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