or was the scenario you were thinking of in u and v modes only?

I just realised we'll have to figure out the PDF generation story also for the source maps spec 😭

@littledan I disagree that MDN is a good solution for discoverability of these values

for example, I may not think to describe a volume of milk differently than a volume of water because in the US they are measured the same, but in other locales that makes a difference

if you're writing a news article, you may not

if you're writing a news article, you may not

For the record, I'm very much opposed to it. It looks good on the surface, but has a terrible developer experience for anything more than the simplest base case

Ok. But I really need some easy way to solve such simplest case ... It's really frustrating that debugging several hours and find that someone just forgotten to pass signal in some inner functions...

Debugging is even harder when transparent things you can't even trace cause issues in the other direction. Finding a forgotten parameter is easy in comparison.

I think it's reasonable for someone to use an AsyncContext variable to establish their own magical transparent cancellation token, as it's on a case by case basis. I would still strongly discourage that practice, though.

Everyone complains or is confused about this in JS.

hax (HE Shi-Jun): you're proving my point. this is actually very complex.

I think the complexity is coming from inconsitant , not implicity itself. For example, in many languages, fn() equal to this.fn() in classes, and it seems ok to developers.

hax (HE Shi-Jun): you're proving my point. this is actually very complex.

But back to cancellation. An opt-in mechanism is "fine", i.e. fetch(url, { signal: "inherit" }). But that means documenting that native API's should always require user opt-in. A native API designer might choose to ignore that and require opt-out, thus it's a slippery slope.

Passing an argument is not complex.

Duncan MacGregor: we do have that already: String.prototype[Symbol.iterator]

well, segmenter allows you to iterate on strings/segment them in many different ways beyond just graphemes

right, but if the only use case i have is to iterate on graphemes, can it be done in a locale-independent way?

in general, we very much do not expose the "root locale". But with graphemes probably any locale will do for now.

I don't like .graphemes living outside Intl but the other two would be great and I would co-champion

both un and und work here on FF

Does Intl/CLDR/etc. have something like an "invariant" locale (i.e., for machine readable formatting, not UI formatting)?

uhhh 🇹🇼

by which I mean it's falling back to my system locale (en-DK)

Is that an intl API for historical reasons? Do graphemes alter with locale in some way I haven't considered?

as far as I can tell:

• unicode has a locale-independent grapheme clustering algorithm
• it recommends the use of CLDR's language-specific rules when available
• CLDR does not appear to have implemented any such rules yet, from what I see https://cldr.unicode.org/development/development-process/design-proposals/grapheme-usage

folks on the queue, please include a topic description beyond just the letter. 🙏

yeah und

still can't edit :-(

so yes it is the system locale I think

Wouldn't b.until(a) be a better replacement for a.since(b)?

I think they are not equivalent, but I don't know exactly how. I suggest asking in the queue so that Philip can respond

ah, though apparently that isn't threaded through to browsers: https://github.com/tc39/ecma402/issues/885

Is there any precedent of sharing methods among several classes?

It's more of a curiosity than a concern.

right, starting point is always the receiver so e.g. with largestUnit: "month", March 31 to April 30 is P1M while April 30 to March 31 is -P30D

I sort of read into it as "I understand if you want subtract" but with an undertone of "If you add it back, remove something else" - maybe that's wrong?

Why is it desirable?

and certainly when 2.7 was introduced I understood it to be about tests

Can we merge the since() and subtract() methods? And they check their receiver

if Shu wanted us to merge random things, he would've said so

implement !== ship unflagged and use in production

I sort of read into it as "I understand if you want subtract" but with an undertone of "If you add it back, remove something else" - maybe that's wrong?

you can use a polyfill for a feature which has never even been proposed if you want to? I don't know what the relevance of "polyfills exist" is to this

the undertone was more like "i understandable, on a case by case basis, if some should be added back. but if too many are added back then we have a problem again"

With the results today, are we in that “problem” state (not yet removing minus or since; not merging toJSON or valueOf yet)?

i'm working through the notes still, but by state you mean items A-L excluding D, E, and F?

for those of us walking to the FF speaker dinner from kamppi metro, meet at the South building entrance in like 10 minutes?

I'd almost rather have since as I'm sure many users would be tripped up by until not being symmetric.

rbuckton: I'm not sure if this was later answered by anyone because there's a long scrollback that I wasn't keeping up with during the presentation; but since is equally asymmetric as until is