References to runtime values and attributes

[eemeli]

Is your feature request related to a problem? Please describe.
With select messages, the case often arises that it's desirable for the selector value (in particular a number) to also be used within a select message, or for the selection to be made based on some attribute of a value that would then be used within the formatted message.

In MF1, the first of these is enabled by using # within a plural or selectordinal. In #52 (comment), @zbraniecki gives an example of the latter. This is also raised in #31 by @grhoten.

Describe the solution you'd like
We should determine how we can avoid error-prone duplication in MF2, so that e.g. numbers in select messages get formatted with the same options with which their cases were selected, and custom functions do not need to be called multiple times with the same arguments.

One option here is to e.g. include something like # in the MF2 data model, and to ensure that custom functions are pure, so that their results may be memoised for later calls with the same parameters.

Another option would be to introduce something like message-specific "macros" or "phrases" that have been suggested by @mihnita and @stasm in conversation elsewhere. The idea is to provide essentially a set of local variables that a message may use in its contents, with their values determined at runtime. This would be the solution that I'd prefer.

Describe why your solution should shape the standard
If such local variables are made available, they'll need a way to be defined in the syntax, as well as have a place in the data model. Using a made-up pseudosyntax, it might look something like this:

msg = [ $bar = number($foo, minimumSignificantDigits: 3) ] $bar ->
  [one] {$bar} thing
  [other] {$bar} things

{
  type: 'select',
  vars: {
    bar: {
      value: {
        type: 'function',
        func: 'number',
        args: [
          { type: 'variable', var_path: [{ type: 'literal', value: 'foo' }] }
        ],
        options: { minimumSignificantDigits: { type: 'literal', value: '3' } }
      }
    }
  },
  select: [
    { value: { type: 'variable', var_path: [{ type: 'literal', value: 'bar' }] } }
  ],
  cases: [
    {
      key: ['one'],
      value: [
        { type: 'variable', var_path: [{ type: 'literal', value: 'bar' }] },
        { type: 'literal', value: ' thing' }
      ]
    },
    {
      key: ['other'],
      value: [
        { type: 'variable', var_path: [{ type: 'literal', value: 'bar' }] },
        { type: 'literal', value: ' things' }
      ]
    }
  ]
}

[markusicu]

From my proposed compromise syntax:

Inside selected patterns,
the selector argument variables must not be used with the normal $ placeholder syntax –
for example, the patterns in the preceding example must not use {$count}.
Allowing that would be doubly confusing:

• It would not be clear which value is inserted.
  In the example, the plural offset is subtracted from the input value,
  and the formatted version of that is what is used for
  evaluating the plural rules and inserting into the pattern.
• It would not be clear what formatting is applied.
  The formatting function and options specified in the selector must be used,
  but {$count} would look like the default formatter might be used.
  Allowing a function-and-options specification here would be even worse.
• (If a developer does need a pattern with both the selector-modified and also the original value,
  then they can pass the value twice into the message formatting function,
  under different argument names.)

[aphillips]

This appears to have been addressed? We now require selector expressions to have an annotation (either directly or in a declaration). Please reopen this issue or open new more-specific issues if you think otherwise.