Description
In a multi-select message, if the selection logic yields values that do not match up to any of the values/conditions corresponding to any of the patterns in the multi-select message, what do we do? Do we require a default case to specified, or not? If we do, how do we specify that default case?
One position in favor for required defaults advocates for a special selection value like likeOTHER as used in ICU MessageFormat to represent default values, and that there should always be only one such default case across the multi-select message. zbraniecki/message-format-2.0-rs#9 (comment)
Another position favor for defaults is #101. This idea details the selection functions that are needed to be applied to selection args to produce the selection case values, but suggests that default cases can be interpreted when the selection functions return a special value (ex: the empty string ""). It says that the use of default values should be avoided / not over-used as a style guide, but we should allow default case checking to happen at runtime, not as a compile time error check.
Another position in favor for defaults is zbraniecki/message-format-2.0-rs#9. Here, the issue describes alternative, some of which encode defaults using an annotation / data struct field. That annotation is separate from the case value(s) that the annotation is attached to.