SIP-72 Dedented Multiline String Literals

[lihaoyi]

No description provided.

[jeremyrsmith]

*Elixir

[som-snytt]

typo .stripMargin. Not sure if transparent inline is addressed for current art of Singleton via custom solution.

[SimY4]

Just a thought, instead of having a new syntax construct, we can probably have yet another standard string interpolator. Can be macro to deal with the problem at compile time.

[lihaoyi]

@SimY4 the proposal discusses why a string inteprolator wouldn't work as well. Specifically, it won't compose with other interpolators like sql"...", it won't work in literal types like val x: "..." = ???, it won't work in literal-only contexts like fastparse.StringIn() or @implicitNotFound("...")

[SimY4]

@lihaoyi on this tho, in terms of what's easier to evolve - a language or a library DSL, I think library is much more flexible in this regard. Libraries can chose to provide DSLs that will deal with margins differently. I did that for my own custom DSLs and it worked pretty great. Users don't have to add strip margin at the end of every string block - it just worked.

Over time you can deprecate and phase out the old DSL from the library. You can't phase it out of the language.

[odersky]

One question: It would be quite straightforward to have a .dedent method that implements the ''' behavior. So instead of

val x = '''
    i am cow
    hear me moo
    '''

we'd have

val x = """
    i am cow
    hear me moo
    """.dedent

The downsides I can see are:

• this is not a constant, so we can't use it as a pattern
• we still need escapes for triple """.
• it's more cumbersome to write (but better than | and .stripMargin).

So the question we need to answer is: are the downsides serious enough so that a new pair of quotes is preferable? I tend to think so, but I'm not 100% certain yet.

[lihaoyi]

The proposal covers a bunch of cases where .dedent wouldn't work:

• Macros expecting literals (e.g. fastparse.StringIn("...")
• Annotations expecting literals (e.g. @implicitNotFound("..."))
• Singleton types (e.g. Iron's constrained types like Match["..."])
• It doesn't allow extensible delimiters to avoid escaping, which the current proposal does (following Swift and C#)
• As you said patterns, and it would be more cumbersome to write that ''' (though better than | with .trim.stripMargin)

A special method would also make things harder for IDEs, since IDEs would need to run typechecking to figure out the contents of the string, whereas with special syntax parsing is sufficient which simplifies things (according to Dmitrii who leads the Intellij-Scala https://contributors.scala-lang.org/t/sip-xx-dedented-multiline-string-literals/7197/94)

A special .dedent would definitely be a smaller change than adding a new syntactic literal. But to me it definitely feels like .dedent would be a half-solution that we would stack on top of an existing half-solution .stripMargin, and if we want to make s change here we should go for the full solution which is a dedicated literal syntax that many other languages seem to be converging on.