Feature toggles for language features

[Lotes]

In detail by Martin Fowler: https://martinfowler.com/articles/feature-toggles.html

Example

Sometimes development of a features takes very long and you do not want to branch out from the main branch for so long. One possible solution for this are feature toggles. You enable or disable a feature depending on a certain condition (for example the current user group is the beta tester or production group).

Depending on this boolean, you branch your programs behavior: Production users get the old implementation, beta testers the new incomplete version.

Feature toggles in Langium

Old syntax

Toggling language features is actually already possible, but based on constants (that are TRUE or FALSE).

Identifier<QuotedStringAsId>: IDENTIFIER | <QuotedStringAsId> STRING;

//use it later with constant
RuleX: 'blubb' name=Identifier<false>; 
RuleY: 'blip' name=Identifier<true>;

terminal IDENTIFIER: /[a-zA-Z_][a-zA-Z_0-9]*/;
terminal STRING: /“[^"]*"/;

You cannot give in a value from outside currently, but it should be a low hanging fruit, since the conditional rules are already part of Langium.

New syntax

What I would like to propose is a new syntax for feature toggles inside the Langium syntax:

//flag name = default value (default should be false)
feature QuotedStringAsId = false;

Identifier: IDENTIFIER | <QuotedStringAsId> STRING;
...

The Langium generator will additionally add an object of feature toggles:

export type MyGrammarFeatureToggles = {
  QuotedStringAsId: boolean;
};
export const DefaultMyGrammarFeatureToggles: MyGrammarFeatureToggles = {
  QuotedStringAsId: false;
};

The toggles can be dynamically set during creation of the services object. Making them accessible through the services, each child service can access the actual values and react properly if needed.

Original problem

This idea came up from a langium-sql issue. LangiumSQL tries to be a SQL solution for multiple dialects. Dialects differ for identifiers:
MySQL likes double-quoted strings as identifiers. For other dialects it can be a string literal, no identifier. A feature toggle was not the original idea, but it would be possible to implement this uncertainty with feature toggles and decide on a dialect when initializing Langium's services object.