Segmenter constructor options/preferences normalization

[sffc]

In #3284 we decided to add a content_locale option to segmenter.

In #5839, @zbraniecki asked some questions about the signature of the constructors.

Currently we have constructors of the following shape:

1. new: singleton static data (infallible), no content locale tailorings
2. try_new_unstable: dynamic data, no content locale tailorings
3. try_new_with_options: static data with content locale tailorings
4. try_new_with_options_unstable: dynamic data with content locale tailorings

Which of the following should we do?

1. Keep all 4 sets of constructors listed above
2. Remove constructor sets 1 and 2. Rename 3 and 4 to not have with_options.
3. Remove constructor set 2. Rename 3 and 4 to not have with_options. Keep constructor 1 as a compiled data infallible optimization.

And, should we take a LanguageIdentifier or a preferences bag for the content locale? (Please understand the discussion in #3284 before stating an opinion on this)

@zbraniecki @makotokato @aethanyc @Manishearth

[aethanyc]

If we were to reduce the number of constructors, I'm leaning toward option 3 to remove constructor set 2. I feel it is not too terrible to ask the user to pass Default::default() as the option to the constructor.

Note: there is probably a naming inconsistency in LineSegmenter. We should prepend try_ to the method name in LineSegmenter::new_auto_with_options, LineSegmenter::new_dictionary_with_options, and LineSegmenter::new_lstm_with_options, because they all take LineBreakOptions which contains content_locale.

[sffc]

@aethanyc I lean toward option 3 a well, but I think we should take the opportunity to give the function ::new() a better name. This is also aligned with the discussion in #5554.

Some ideas:

• new_root
• new_invariant
• new_without_options

[sffc]

@Manishearth @makotokato @zbraniecki, anything to add to the list above?

What should we name the segmenter constructor that takes no arguments, uses compiled data, is infallible, and uses Unicode data with no CLDR locale tailorings? (It is currently named ::new() but there are reasons we want to change it.)

[Manishearth]

Not a huge fan of using the somewhat-CLDR-internal concept "root" in the name. new_untailored or new_no_tailoring? (tailoring is also a bit of jargon, but it's jargon in the segmentation space, not specific to CLDR. Unclear to me if that distinction actually matters)

[makotokato]

I don't have strong opinions for this. Actually we have no plan to add new options. If we support auto-phase in css text, it can add it in css property.

[Manishearth]

#5958 adds new_root or new_root_foo to all segmenters except Grapheme.

We can rename root to something else if we want, I am happy with root for now. We should perhaps get WG approval on the name.

We should also figure out what we want to do with Grapheme. Grapheme does not support any tailorings right now, but it could in the future? I'm inclined to let Grapheme have a new() and use the deprecation route if we need to split it.

[aethanyc]

We can rename root to something else if we want, I am happy with root for now. We should perhaps get WG approval on the name.

I like new_without_options proposed in #5856 (comment). Although it is a bit mouthful, but it clearly indicate that it accepts no options like WordBreakOptions or LineBreakOptions.