Good points. Like I said, I think we are in agreement! —Guy
> On Apr 22, 2019, at 8:00 PM, Alex Buckley <alex.buck...@oracle.com> wrote:
>
> On 4/22/2019 12:16 PM, Guy Steele wrote:
>>> On Apr 22, 2019, at 3:04 PM, Alex Buckley <alex.buck...@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
