Wrapping up the first two courses

[Brian Goetz]

A few more questions have been raised:

 - Do we do alignment before, or after, escape processing?  
 - What about single-line “fat” strings?  
 - What is the effect of text on the first line on alignment?
 - What about opt-out?
 - What about \<newline> ?

Suggested answers:

1.  Escape processing.  If alignment is about removing _incidental indentation_, it seems hard to believe that a \t escape is intended to be incidental; this feels like payload, not envelope.  Which suggests to me that we should be doing alignment on the escaped string, and then doing escape processing.  

For 2/3, here’s a radical suggestion.  Our theory is, a “fat” string is one that is is co-mingled with the indentation of the surrounding code, and one which we usually wish the compiler to disentangle for us.  By this interpretation, fat single-line strings make no sense, so let’s ban them, and similarly, text on the first line similarly makes little sense, so let’s ban that too.  In other words, fat strings (with the possible exception of the trailing delimiter) must exist within a “Kevin Rectangle.”  

For 4 (opt out), I think it is OK to allow a self-stripping escape on the first line (e.g., \-), which expands to nothing, but suppresses stripping.  This effectively becomes a “here doc”.  

For 5, since \<newline> is not valid today, we don’t have to decide this now, we can add it later if desired.


> So, I posit, we have consensus over the following things: 
> 
>  - Multi-line strings are a useful feature on their own
>  - Using “fat” delimiters for multi-line strings is practical and intuitive
>  - Multi-line string literals share the same escape language as single-line string literals
>  - Newlines in MLSLs should be normalized to \n
>  - There exists a reasonable alignment algorithm, which users can learn easily enough, and can be captured as a library method on String (some finer points to be hammered out)
>  - To the extent the language performs alignment, it should be consistent with what the library-based version does, so that users can opt out and opt back in again
>  - In the common case, a MLSL will be a combination of some intended and some incidental indentation, and it is reasonable for the default to be that the language attempts to normalize away the incidental indendentation
>  - There needs to be an opt-out, for the cases where alignment is not the default the user wants