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.buck...@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.
>
> (
