| 03:49 | <ljharb> | TabAtkins: i'm finishing the polyfills for `item`, and i'm curious - what should `'abc'.item(-4)` return? `'abc'.item(3)` should obv return undefined, but should `-4` return undefined, or should it be the same as `'abc'.item(-1)`? the current algorithm seems to make it equal to `'abc'.item(0)` which seems weird |
| 03:50 | <ljharb> | like, i'd expect modulo/wrapping, or undefined, but i wouldn't expect "everything that tries to go before 0, provides 0" |
| 03:53 | <ljharb> | (oops, obv the string one would produce the empty string while the array one produced undefined, but, same question) |
| 03:55 | <devsnek> | ljharb: `this.len + index` |
| 03:55 | <devsnek> | oh nvm i get what you're asking |
| 03:55 | <ljharb> | right |
| 03:56 | <ljharb> | the current "relative" math works when it the positive or negative number is within 0,length |
| 03:56 | <devsnek> | ya |
| 03:56 | <Bakkot> | undefined, I would expect |
| 03:56 | <devsnek> | if you go around more than once it forces it to be 0 |
| 03:56 | <ljharb> | but if you pass ">= length", you'll get undefined/empty string, as expected |
| 03:56 | <Bakkot> | see what Python does with its negative indexes |
| 03:56 | <ljharb> | but if you pass `<= -length`, that's not what the current spec does |
| 03:56 | <devsnek> | i like undefined for that |
| 03:57 | <Bakkot> | python gives RangeError, which means we should give undefined |
| 03:57 | <ljharb> | (because of the `max(?, 0)` |
| 03:57 | <ljharb> | Bakkot: i agree |
| 03:57 | <ljharb> | ok, i'll make a PR to fix the spec |
| 03:57 | <Bakkot> | *IndexError is I guess what they call it |
| 03:57 | <Bakkot> | I think there is an issue about thiis? |
| 03:57 | <ljharb> | oh |
| 03:58 | <Bakkot> | mahttps://github.com/tc39/proposal-item-method/issues/11 |
| 03:59 | <Bakkot> | I have no idea where that "ma" came from |
| 03:59 | <devsnek> | aha the built spec just needs to be updated |
| 04:00 | <ljharb> | my internet's having trouble, but i can make a PR for that shortly |
| 04:01 | <Bakkot> | gotta make CI enforce that git state is clean after `npm run build` |
| 04:01 | <ljharb> | i suppose i could add that too |
| 04:02 | <Bakkot> | I guess that would involve _having_ CI, first |
| 04:02 | <Bakkot> | which is maybe a burden not worth the benefit |
| 04:02 | <TabAtkins> | ljharb: Clamping isn't the current spec. |
| 04:03 | <Bakkot> | maybe it is worth it though, especially once I get linting in a state where it works for proposals |
| 04:03 | <devsnek> | multipage will be key for proposals |
| 04:03 | <devsnek> | :P |
| 04:03 | <TabAtkins> | Oh wait nm, the spec proposal hasn't been updated yet, ugh. |
| 04:03 | <Bakkot> | devsnek lol |
| 04:03 | <Bakkot> | I'll get to that PR at some point before the next release probably |
| 04:04 | <devsnek> | cool |
| 04:04 | <Bakkot> | (no guarantee I'll merge it before the release though) |
| 04:04 | <ljharb> | TabAtkins: looking at https://tc39.es/proposal-item-method/ |
| 04:04 | <Bakkot> | have to figure out what I'm doing about ecma402's normative-optionality before I cut a new release |
| 04:04 | <TabAtkins> | Huh, maybe it hasnt' been built yet? https://github.com/tc39/proposal-item-method/commit/5235acba371d18dcca6383c9f0e25cdbd518a7f6 fixes it to return undefined for oob |
| 04:04 | <devsnek> | did you see the normative optional thing I put in the __proto__ pr |
| 04:04 | <ljharb> | TabAtkins: i think it's what Bakkot said above; CI doesn't force `npm run build` to be run |
| 04:04 | <devsnek> | I stole it from the weakref proposal |
| 04:05 | <ljharb> | TabAtkins: i'll make a PR shortly to bring in the github action that automates doing that, from the templat |
| 04:05 | <devsnek> | but it looks nice |
| 04:05 | <devsnek> | you could use that |
| 04:05 | <Bakkot> | ah, sorry, I should have been more clear |
| 04:05 | <Bakkot> | 402 has normative-optional steps |
| 04:05 | <devsnek> | ohno |
| 04:06 | <TabAtkins> | ah, danke |
| 04:06 | <devsnek> | hm actually I guess we do too |
| 04:06 | <devsnek> | because we decided to make Optionally, do X |
| 04:06 | <Bakkot> | which they accomplish like this: https://github.com/tc39/ecma402/blob/62583d85e66bcec8639153347119d3fb1b99387d/spec/numberformat.html#L704-L716 |
| 04:06 | <devsnek> | even though X is already a host hook |
| 04:06 | <ljharb> | TabAtkins: as soon as comcast stops being broken :-p |
| 04:06 | <Bakkot> | and ecmarkup's linter does not like starting steps with indices other than 1, because I assumed the step-references thing would suffice to get rid of those |
| 04:07 | <Bakkot> | so I will probably teach ecmarkup about this pattern as well, so that this pattern does not require you to explicitly include the offsets |
| 04:07 | <devsnek> | I'd say, [optional] |
| 04:07 | <devsnek> | [optional, id=x] |
| 04:07 | <devsnek> | etc |
| 04:07 | <Bakkot> | yeah, the alternative is to introduce a new pattern and PR 402 to use that |
| 04:08 | <Bakkot> | but I kind of prefer not changing what's there |
| 04:08 | <Bakkot> | but only kind of |
| 04:08 | <Bakkot> | not sure yet |
| 04:08 | <devsnek> | I think it's definitely bad for there to be explicit step numbers |
| 04:08 | <Bakkot> | right, any approach will result in that not being there |
| 04:09 | <Bakkot> | "teaching ecmarkup about this pattern" means teaching it to compute the right offsets itself when it encounters this pattern |
| 04:09 | <devsnek> | I guess the question is what's best for multiple steps in a row being optional |
| 05:26 | <ljharb> | TabAtkins: https://github.com/tc39/proposal-item-method/pull/18 |