Allowing full-message variants to end without indention about fluent

[zbraniecki]

It feels to me like it's the most pronounced papercut people have been encountering so far. It also is my personal aesthetic pet peeve.

I find this:

key = { OS() ->
    [mac] Mac
   *[other] Other
}

over:

key =
    { OS() ->
        [mac] Mac
       *[other] Other
    }

and I'd say that if cannot come up with a way to make what feels natural work (as per original FTL design approach we took), and instead require a quirk, that would be sad.

[stasm]

As a first step, I suggest to only allow no indentation in values which start immediately on the line of identifier =. This would in practice mean defining two different value productions in the EBNF: inline-value and block-value. By doing so, I would like to allow this:

foo = { $num ->
   *[other] Other
}

…and this:

foo =
    { $num ->
       *[other] Other
    }

…but not this:

foo =
    { $num ->
       *[other] All
}

The last snippet suggests that it's okay to continue the multiline value without indentation, like so:

foo =
    Lorem ipsum { $num ->
       *[other] dolor
} sit amet, consectetur
adipiscing elit.     // syntax error

[stasm]

I'd like to err on the side of consistency. Here's a linter rule that I would like to suggest:

If a Pattern contains a TextElement with \n or a SelectExpression, it should be written starting from a new line.

The following valid FTL:

key1 = Foo
    Bar

key2 = Foo { $arg ->
       *[one] One
    }

would pritty-print as:

key 1 =
    Foo
    Bar

key2 =
    Foo { $arg ->
       *[one] One
    }

[stasm]

I think it would be possible to allow this as syntax sugar (no changes in the AST) by something like:

value ::= pattern | '{' __? block-expression WS? '}'

…where WS represents any white-space, with and without line breaks and with and without indentation.

[stasm]

By "no changes in the AST" I mean that the value field of a message written using the syntax sugar would still consist of a Pattern with a single Placeable in which there's a SelectExpression (with or without the selector).

This allows to always assume that a message's value is a Pattern.

[stasm]

I opened #74 with the proposed implementation in the EBNF.

Introducing this syntax sugar makes the parser more tolerant to input. OTOH, I'd like the serializer to continue to use the canonical syntax:

foo =
    { $num ->
       *[other] Other
    }

[stasm]

I backed this out in #81; see the comments there for the rationale. I'd like to consider this again in the next milestone of the Fluent Syntax along with other improvements to relax the indentation requirements.

[stasm]

This is now scheduled to land in Syntax 0.7 as part of #87.