To me, the fact of an error is more important than the fallback representation. Showing the fallback representation to end users is less good than having good error recovery (or no error at all). This wording makes the fallback representation first and thus, seemingly, the more important thing.

I also find the "MUST or MUST" formulation to be weird. I think this is trying to say "MUST provide some representation of the message or an informative error or errors or both"

I think it would be weird if an implementation never failed, that is, if it returned the fallback representation silently with no signal of failure. When would this be a good thing? How would the caller find out about the error.

Note that we do not specify how errors are signaled. Just because (for example) Java often throws Throwable does not mean that the MF2 implementation has to use that as the error mechanism. See, for example, the use of ParsePosition in NumberFormat.

Thus I'd suggest an additional alternative:

I applied most of the suggested change in order to address the simplification of the "MUST or MUST" construction.

Now, the reason for that verbose wording was to be as least restrictive as possible. It's basically saying, "You do something when you get an error. You must provide a best effort message or an error, maybe both. You can't do nothing."

The point about requiring signaling that an error occurred is an extra constraint beyond the existing text. I think it is a reasonable constraint, so I will incorporate that. But I'm not comfortable strengthening that constraint anything further because as we discussed in Monday's meeting, there is a big difference in "error" (ex: instance of java.lang.Exception) versus "signal that an error occurred" (ex: have just a boolean, or have a "strict version alternate API"). In order to avoid ambiguity about that, I much prefer "signal an error" rather than "provide an error" (this potential ambiguity is why I prodded us in Monday's meeting to be specific about what we mean by "provide/return an error")

I also think it would help avoid ambiguity to say "be able to signal" rather than "signal" so that we more clearly support implementations that choose to meet the requirement with an alternative that uses 2 APIs (ex: an infallible best-effort and a strict fallible one that signals an error). I think that would also address Tim's concern in his review comment since we have all been comfortable allowing choice by implementations since the time it was brought up 2 months ago.

I would probably say:

One reason is that throwing an exception (in languages that do that) is not the same as returning a return value.

How about "signal" instead of "emit"?

I used the word "signal" instead of "emit" because that better accomodates all of the alternatives in the solution space.

Note: I had to rewrite this section to reflect the extra constraint that I am taking on from your suggestion in the other conversation thread, since this section existed to clarify the spec text concretely and in plain words.

What execution environment constraints does this alternative contravene? The only such mentioned in this document is that the cost of returning more than one error may be prohibitive in some cases, and the current text explicitly says "error or errors" to allow for an implementation signaling a single error to be valid.

The text says "an informative error". As written, that implies to me an error object, like a java.lang.Throwable instance. Despite discussion in last week's meeting to interpret that phrase as equivalent to "whether or not an error occurred", it comes across distinctly as something more and thus should be rewritten if the intent is not so. There are applications like ICU and potentially browsers that might only want to provide a best effort message and signal an error, but not pay the cost of creating "informative error" objects each time.

As I mentioned in the 2024-04-09 meeting, another paradigm from which to look at this, besides "whether is returning an error possible", is "how actionable is returning the error object". ICU & browsers need to be performant and might not want to pay the cost of the creating a full error object.

This applies to all solutions that require a runtime error to be signalled in some way, right?

The point here is that if you're already returning a best-effort result from a formatter, then in ICU, it hasn't been useful to deal with the ErrorCodes altogether because the calling code is not looking for it. So for ICU, trying to use the ErrorCode in such cases is optional at best, but confusing and hard to reason about at worst. There's no benefit to dealing with the ErrorCode in these cases. And that's the general approach they arrived at over time dealing with formatter code. That's my interpretation & recollection of the linked discussion.

Those ICU guidelines seems reasonable for ICU, since ICU can't fail so it has to return something. Assuming "solution" = MF2 implementation, then yes, it seems reasonable and generally applicable advice for other implementations, although the guidelines that make sense to other implementations depend on each of their designs & use cases.

The fact that the current spec text takes a strong universal stance on what implementations must do, when that doesn't actually fit all use cases / guidelines / PLs, is still the crux of the matter.

By "solution" I meant the choice of spec language that we are debating here.

As I understand it (and please do correct me if I'm wrong), the ICU experience-based programming guideline in this case is roughly speaking, "You should not report formatting errors if you can fallback to some formatted result."

My point here is that this guideline applies to all spec text choices which require an error to be reported; for example, the current proposed design states:

In all cases, when encountering an error,
a message formatter MUST be able to signal an error or errors.

Therefore, that choice would also go against the above-mentioned experience-based programming guidelines. Is this not the case?

Just to be clear, I disagree about following this guideline for MF2, but here I'm trying to make sure that it's logically and consistently applied as it's being used as an argument in choosing between alternative designs.

We've had some good discussions in telecon about these cases. We should use the design doc to capture some of this for posterity. I'm going to suggest a use case section below.