Allow expressions without annotations to dynamically choose a function

[aphillips]

Fixes #42

Also addresses some problems with normative terms in the same text.

[macchiati]

One other consideration: we should discuss whether enabling the conversion of MF1 messages to MF2 messages is a desired feature. I suspect the biggest barrier to that would be if a conformant implementation *cannot* perform automatic choice of functions, with strongly typed languages.

…

On Mon, Aug 28, 2023 at 9:28 AM Eemeli Aro ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In spec/formatting.md <#456 (comment)> : > +An implementation MAY use the value of an _expression_'s _operand_ +to choose a _formatting function_ and default _options_ if no +_annotation_ is supplied by the _expression_. If we allow for casting literals to non-string types, we'll need to remove that assertion I disagree, I think. The *resolution* of a text or literal would always succeed, but the formatting might be different. These are separate operations. We're getting into semantics, but you are indeed right if we consider the string-without-pattern-matching-applied as "resolved". In other words, we could leave the assertion in, but we would need to add in a much more restrictive definition of "resolved value" than we currently have, because that could not include the resolution of a string '12345' as a numerical value. we will no longer be able to say with certainty e.g. that this message will always format to the same string in all implementations It is already the case that the same message might not format to the same string in all implementations--because, for example, they are running different CLDR versions or the locale resolves slightly differently on a given platform. In general yes, but my point was about the specific string including an explicit literal. It does currently format to the same string in all possible implementations. The example you provided with {12345} is a good one, since it highlights the problem of untyped or weakly typed values, which this proposal brings to the fore. In my understanding, the value represented in {12345} is always a string, and only ever a string. Its value could be parsed as a number, but it's still a string. This is, to some degree, a loss of functionality for strongly typed languages vs. MF1 This is not the case No, I'm pretty sure it is the case. MF1 lets you write simple patterns that don't declare a formatter and uses reflection to assign the formatter at runtime, e.g. {0} formats a Number, Date, or String differently and using the appropriate formatter. Whether that capability is important is what we're discussing 😉. Just as a sanity check, I'm presuming that the {0} you're using is an MF1 reference to an external variable, yes? If so, that's completely separate from this discussion on literal values that are wholly and completely defined in the message syntax. Wouldn't you feel a bit of surprise if you didn't get the same behavior when you did a local assignment? Not if we make it clear that the value of an unannotated literal is always a string. On the one hand, I do think that requiring the annotation is super helpful (particularly to translators, who cannot see what type is being passed), but that suggests that we require an annotation all the time. The we should also define a :string function. The question of clear and significant benefit is whether developers can get "do what I mean" behavior. We should seek group consensus here. Agreed. — Reply to this email directly, view it on GitHub <#456 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACJLEMHOXC6PPTO5UOKTYI3XXTBLZANCNFSM6AAAAAA3WWL5EM> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[aphillips]

@macchiati We discussed this in teleconference today. Implementations will be allowed to choose how to process values based on type without having a specific annotation, so that level of compatibility will be present.

[aphillips]

Here is the first cut at adopting the consensus from the 2023-08-28 call. I suspect that examples are needed. In particular, while the normative text allows implementations to make the kind of inference we're talking about here, it might not be clear to readers.

Let's make the normative gunk first, although I welcome suggestions for how to make this clear. I'm going to toy with some examples.

[eemeli]

I added a merge from main to fix the Prettier action. A small bunch of stylistic fixes inline; otherwise this starts to look like an improvement on what we've currently got.

[stasm]

Catching up with the developments of the past two weeks. LGTM :)