Should %Segments% instances have a link back to their Intl.Segmenter?

[gibson042]

It could be useful for e.g. iteration from an arbitrary point.

-function* segmentsAfterIndex( segments, index, segmenter ) {
+function* segmentsAfterIndex( segments, index ) {
   let match = segments.containing(index);
   if ( !match ) {
     return;
   }
   let offset = match.index + match.segment.length;
   let tail = segments.string.slice(offset);
-  for ( let tailSegment of segmenter.segment(tail) ) {
+  for ( let tailSegment of segments.segmenter.segment(tail) ) {
     tailSegment.index += offset;
     yield tailSegment;
   }
 }

[sffc]

LGTM

[littledan]

No particular concerns, but it also doesn't sound so bad to have to pass the segmenter around.

[gibson042]

Options for avoiding the "exotic internal slot" hazard:

1. Change segmenter from an accessor property on the prototype to a data property on the instance (Normative: Define Segments instance properties #108, matches proposal-promise-any errors property).
2. Change segmenter from an accessor property on the prototype to a method that returns a fresh segmenter.
3. Remove segmenter, leaving string.
4. Remove both segmenter and string properties.

I don't like option 3 or 4 because they strip out too much from a Segments instance, and option 3 in particular is distasteful because having the string without the segmenter excessively limits what can be done with it. Option 2 can work but seems out of place. I personally favor option 1, in line with the decision from tc39/proposal-promise-any#38 .

[anba]

I prefer to wait for the broader discussion as suggested by @littledan before we try to reach consensus on any of the proposed options.

[gibson042]

Resolved in today's ECMA-402 call to sidestep the concern by removing both segmenter and string properties from segments instances, but preserving the ability to recover the input string by exposing it on iteration results per #116.

[littledan]

In the July 16th SES call, @erights and I arrived at the conclusion that there is no need to avoid internal slots in cases like Intl.Segmenter and Temporal classes, where

1. Internal slots are accessed just on the this value.
2. No new "undeniables" (objects accessible from syntax) are being added
   Cases which run into one of these two constraints might be acceptable; it just takes more specific analysis. Intl.Segmenter does not run into these constraints, though.

If the change in #117 is justified by other aspects of good design, I'm fine with this decision . I don't think we should consider the "exotic internal slot hazard" a reason to make API design decisions, though.