To align, or not to align?

[Brian Goetz]

I think we're at a point where we're ready to make the next big decision.

So far, we seem to be converging on a reasonable definition of 
"alignment" for multi-line strings, modulo a few small choices (e.g., 
what to do about single-line strings, etc.)  Jim has posted a 
prototype.  This could be exposed as either a language feature, or a 
library feature, or both.

The question we're now ready to confront is: how should a user indicate 
that they do, or do not, want alignment?  Options include:

  - Align by default, with some sort of opt-out
  - Do not align by default, with some sort of opt-in
    - Opt in could just be a library invocation, such as `String::align`
    - Opt in could be a linguistic marker

(Note: we are not ready to discuss syntax yet, we're still discussing 
how the language works.)

Arguments for align-by-default:

  - General feeling (hopefully to be bolstered by data soon) that _most_ 
embedded ML strings are "programs" in languages like HTML, XML, JSON, 
YAML, SQL, etc, which naturally use indentation and users will generally 
want to strip off the incidental indentation caused by embedding in Java 
source.

  - Incidental indentation is a natural, but accidental, consequence of 
embedding ML strings in a program.

  - Early feedback included plenty of complaints about "why do I have to 
say `.align()` all the time?"

  - We don't want to leave users with a perceived bad choice: either say 
`.align()` explicitly, or mangle your source code to not have incidental 
indentation (making it look bad), or live with extra indentation.

Arguments against align-by-default:

  - The language should provide a _simple_ facility for string literals; 
the complexity of alignment does not belong in the language.

  - Alignment is not always what the user is going to want; even if it 
is, the built-in alignment algorithm may not be exactly what the user is 
going to want.

  - It is not an orthogonal decomposition; we're tying ML-ness to 
alignment.  The language should expose primitives that the user can 
combine compositionally.

  - It interacts badly with string concatenation.


Note that the "for" arguments are mostly pragmatic, and the "against" 
arguments are mostly principled.  (That is not to say we shouldn't 
decide for "for"; this feature is, after all, purely about user 
convenience, since these strings can be expressed already in the 
existing language.)

Now accepting arguments one way or the other.  (Not yet accepting 
comments on syntax.)