String template literals: Additional Features

PR 2599 implements string template literals in a way that is a non-breaking change with Reason Syntax 3.6.

It is good to go as is, but there's a couple of features that should be considered before cutting the release, as well as some features that should be added after cutting the release.

Pre-release

Auto-indenting [DONE]

String template literals will be interpreted according to the indentation of raw white space immediately before the closing backtick:

module MyModule = {
  let x = `
  this is some text
  here that spans multiple lines.
  `
};

However, it will print them with an additional indentation between the ticks so that it matches how other constructs wrap/pretty print:

module MyModule = {
  let x = `
    this is some text
    here that spans multiple lines.
  `
};

This is so that, eventually, pretty printed inline string templates look like all the other constructs indented. This is so that not only are the strings indented like everything else, but so are the closing parens:

Printf.fprintf(fmt, `
  text here
  and here
`);

Prose Templates [UNDECIDED]

In most cases, when you are creating a multiline string, it is handed off to some other formatter that implements text wrapping. For JS this is the DOM, and for command line output it's something like the Format module. A "prose" mode allows you to have newlines in the strings, without actually inserting newlines in the text.

let x = `
  this is some text that you can see
  here that spans multiple lines.
  But it's actually one line.

  But then if you want an actual newline, you
  enter an additional newline as above.
`

• A newline causes a single white space character instead of a newline.
• This allows refmt to wrap the text tokens according to the editor width (or if you move these literals to greater indented contexts).
• This should probably be the default since most tools that print strings do their own formatting that needs to be composable.
• It would require a non-prose mode to allow multiline literals with explicit newlines.

let nonProseMode = ``
  These will be actual newlines
  not virtual ones.
``

Type Safe Interpolation [UNDECIDED]

Before cutting a release, we just need to implement a syntax parsing for this feature, even if it's not implemented yet (so that people upgrading to the next next release will have identical semantics. The idea here is that interpolation can select between different types.

let x = ```
  This is a ${stringExpression()} and this is an %{integerExpression}
  and this is #{somethingCustom}

Challenges:

• String templates require different conventions for type safe interpolation depending on the use case.
• Printf requires something different and has more interpolation features than simple string concatenation but both should be supported.

Post-release

JSX Type Safe Interpolation

JSX can use the same exact string prose convention, and doc comments can use the same convention as well.

let x = <div>
  regular text heere
  ${myString} %{someInt}
  #{customElement}
  regular text
</div>

• JSX would need a non-prose opt-in just like string template literals.
• This would probably be implemented as a lossless transform at the parsing stage, and allow other ppxs and allow dedicated backend specific transforms to clarify the meaning of the interpolation and text content.

If string templates are "Prose Templates", and JSX abides by the same exact convention, then things in the editor can format more beautifully, and there's only one convention to learn everywhere.

Start by reviewing PR 2599 and the issue's pre-release and post-release sections. The scope is not settled: prose templates, type-safe interpolation, and JSX interpolation are marked undecided or proposed. Done would require an agreed design and implementation plan before any focused contribution can begin.