Add some capabilities for the builtin functions

[ryzokuken]

As a precursor to finalizing and standardizing the set of builtin functions, we should document the "goals" of the builtin API.

This PR aims to kick off that process by adding a simple list of capabilities that we aim to expose to users. This list is close to the set of functions exposed by the ECMA-402 API and a superset of the API documented by #420. Some notable exceptions include:

• The list of formatters excludes relative time formatting and durations. It is my understanding that RelativeTimeFormat was never the most elegant part of the Intl API and its future use would be discouraged. Durations could be added as a follow-on, but I wasn't sure about it.

• The list of selectors include a "gender" selector. This functionality doesn't exist in 402 and I didn't yet investigate whether it's exposed by ICU. That said, it was a recurring theme in a number of documents I read (in this repository, I think?) and I felt it might be uniquely useful within the context of MessageFormat so I decided to include it here but don't feel very strongly either way.

This is super WIP so feel free to tear it apart but I hope it's a decent launch-off point for our work.

[CLAassistant]

All committers have signed the CLA.

[ryzokuken]

Will figure out what's the best way to deal with the CLA.

[aphillips]

Thank you for starting on this!!

In the call this week we established a new bit of process. I think this PR would be better off as a design document. See here for the template. Create a new proposal using the template under /main/exploration and that'll be easier to discuss. As you can see from my comments below, trying to be "specification like" and working on what to put in the built-in registry doubles the effort.

[ryzokuken]

Okay moved the text to the exploration dir, made some structural changes and tried to incorporate your comments.

@aphillips how does it look?

[eemeli]

For some reason the prettier formatter hasn't run on this branch, and that'll need to be fixed. Otherwise, some minor issues inline.

[ryzokuken]

The prettier action seems to be broken, here and elsewhere (#456). Should I file an issue about it?

[eemeli]

The prettier action seems to be broken, here and elsewhere (#456). Should I file an issue about it?

See #464.

[ryzokuken]

I don't have the permissions to rerun this job but now it should have access to my branch 🤞

[ryzokuken]

Weird, looks like prettier behaves differently but either way, this should be good now. :D

[eemeli]

Minor indent fix inline, but otherwise looks good to land as "proposed". So this is conditional approval presuming that #461 is accepted first; otherwise all the TBD needs to be D.

[ryzokuken]

@eemeli dunno why prettier did that but thanks for the fix! I'm assuming that we're happy with #461 and that we can flesh out this document further after merging but in the meantime I'll start working on the remaining sections

[ryzokuken]

Added some pretty tentative text for the other sections so that atleast all sections exist.

[ryzokuken]

@eemeli @aphillips sorry for dropping the ball on this somewhat. I've now put in some improvements that I felt brought the doc closer to what you expected and applied some of Addison's comments. Please feel free to let me know if there's anything else here that needs rewording or polishing.

[ryzokuken]

@aphillips thanks for all the suggestions and apologies for the delay. Some of your suggestions I applied as-is, but mostly I tweaked the draft to make it closer to what I think you expected. Let me know what you think

[aphillips]

Looking good. Some minor tweaks.

The use cases and requirements need to be fleshed out as we go.

@eemeli has started work on the number selection design in another PR, so maybe don't focus on that.

I think one really interesting area we need to work out are the options for numbers and for date/time values. ICU has developed "skeletons" for both of these, but JS generally has not adopted skeletons in favor of (somewhat verbosely named) bags of options. We have some consensus to use the option bags, but we should spell out the options for each and then check that it matches what both JS and ICU provide.

I think it would be interesting to consider providing an optional but defined set of options for skeletons. That is, not require an implementation to support them, but require implementations that do support them to define them using our definition.

Anyway, fix the typos and then (if the group concurs) we can merge for further work.

[ryzokuken]

@aphillips applied your straightforward suggestions and rephrased the remaining item in "constraints". Some of the sections are far from ideal indeed but I do feel that fleshing things out as we go would be the best mode since this would just be a "proposed" draft at the moment.

[aphillips]

@ryzokuken thanks!

Let's merge this and iterate on it.