Language involving "field set", "field set with options", and "semantic skeleton"

[sffc]

Split from #6242

According to UTS 35, a "field set" is the set of fields, such as "year, month, and day". A "semantic skeleton" is a field set coupled with formatting options such as length and alignment.

We are a bit loose with this distinction in ICU4X docs and APIs. Part of this is because we define a type per field set, like fieldsets::YMD, but that type is a struct that contains options. We also have APIs such as FieldSetBuilder, which should really be a SemanticSkeletonBuilder, but we don't use the term "semantic skeleton" anywhere in our API.

@markusicu had suggested "field set with options" to avoid the "semantic skeleton" terminology, which is a bit heavy on technical jargon. Implementing that change would involve changing a bunch of parameters and variables currently named field_set to instead be field_set_with_options (non-breaking). If we want to be strict, it would also involve renaming FieldSetBuilder to FieldSetWithOptionsBuilder (breaks 2.0). There may be other APIs also impacted.

Thoughts?

@Manishearth @robertbastian

[Manishearth]

I'm in favor of renaming the variables and parameters. I think having the types still be FieldSet is preferable, even if they contain options: the problem is that at a type level they're fieldsets, and they're used as marker types, but they're not marker types, they contain options too. We could have theoretically gone with a design that had FSet markers and associated FSet::Options bags but that would be more types and I don't think it's a good idea.

Barring that, their primary purpose is still to be markers IMO, so we should call them FSets at the type level, and include with_options in variables at the value level. I think that's a principled approach.

(This means status quo for 2.0, parameter renaming for stretch)

[sffc]

We also have the types DateFieldSet and CompositeFieldSet (and other *FieldSet) which are also used as the type-level FSet but are more forward in being a semantic skeleton.

According to UTS 35, these should be named DateSkeleton and CompositeSkeleton (perhaps SemanticSkeleton). According to @markusicu's suggestion, they could be DateFieldSetWithOptions and CompositeFieldSetWithOptions.

[Manishearth]

For the runtime types yeah that makes some snse.

[sffc]

If we introduce the word Skeleton into the API, then FieldSetBuilder should be SkeletonBuilder.

I'm not particularly excited about the verbosity of DateFieldSetWithOptions or FieldSetWithOptionsBuilder so I'd like to remove that from contention.

Personally I'm okay with either of these outcomes:

1. Rename arguments to field_set_with_options but otherwise keep FieldSet in the name of things like FieldSetBuilder, DateFieldSet, and CompositeFieldSet
2. Change these types to Skeleton, such as SkeletonBuilder, DateSkeleton, and CompositeSkeleton, and rename the arguments also to skeleton. Possibly reconsider the module names.

(1) is easier. I don't really want to put in the work to do (2) unless we think it is really important.

[Manishearth]

I think Skeleton is very CLDR specific; FieldSet is also jargon, but it's a bit better at explaining what it does. It took me a while of working on this stuff before I could reliably distinguish "skeleton" and "pattern".

I like (1). I have no strong position on the runtime fieldset names, they could say fieldset, or they could say fieldsetwithoptions.

[sffc]

Okay, I'm inclined to triage this as 2.0 Stretch to change the parameter names and improve docs.