String reboot - (1a) incidental whitespace

[John Rose]

That's an interesting use case:  The original string expression is multi-line,
but all of the line terminators are in the envelope, not the payload.

If I were writing this as a single literal in Bourne shell I might consider
using a formulation that breaks the long line into several smaller lines:
  PREP_STMT="\
      SELECT * \
        FROM my_table \
        WHERE a = b \
  "

Supporting that in Java MLS would requires a notation (I won't speculate
what ATM) to mark newlines in the MLS as "syntax only, not payload".

(By payload I mean the actual characters requested in the resulting string.
By syntax I mean the program source which denotes the literal making
the request for a string.)

By making a distinction between payload and syntax, for newlines
in a MLS, we have the following possibilities:

syntax element | meaning
LineTerminator | newline is both payload and (post-normalized) syntax
\ n                   | newline is payload only, not syntax (syntax is an esc. seq.)
TBD?                | newline is syntax only, not payload (newline is suppressed somehow)

The TBD category is currently occupied by the strippable newlines just after
the open-quote and just before the close-quote.  Might there be a use for
a strippable newline in the middle of the MLS?  It would cover Alex's use
case.

Maybe Alex was just describing an attractive nuisance, not a real use case.
But I know that breaking long lines into shorter ones is something that
programmers do all the time.  MLS is sort of the opposite:  Joining short
strings into long multi-line ones.  Yet both tasks involve fine control of
program layout.  So it's not an accident that MLS leads us to discuss
syntax-not-payload newlines, even if the main driver for MLS is to
introduce both-syntax-and-payload newlines.

The main thing Brian is waiting for, though, is not lots of new ideas,
but rather a consensus that (a) we can treat leading whitespace outside
of a given rectangle as syntax-not-payload (thus stripped), and (b) that
we should provide a way for programmers to opt out of the stripping
(making all space into syntax-and-payload).  It feels to me like we
have arrived there and are driving around the parking lot, checking
out all the parking spots, worrying that we will miss the best one.

— John

On Apr 19, 2019, at 5:16 PM, Alex Buckley <alex.buckley at oracle.com> wrote:
> 
> Going forward, who can guarantee that refactoring the argument of `prepareStatement` from a sequence of concatenations:
> 
>  try (PreparedStatement s = connection.prepareStatement(
>      "SELECT * "
>    + "FROM my_table "
>    + "WHERE a = b "
>  )) {
>      ...
>  }
> 
> to a multi-line string literal:
> 
>  try (PreparedStatement s = connection.prepareStatement(
>      """SELECT *
>         FROM my_table
>         WHERE a = b"""
>  )) {
>      ...
>  }
> 
> is behaviorally compatible for `prepareStatement`? It had no reason to expect \n in its string argument before.
> 
> (