| 02:41 | <devsnek> | exciting times |
| 17:40 | <ptomato> | is it a normative change to turn ! into ?, if the ! assertion was incorrect? |
| 17:40 | <yulia> | I believe so -- it changes the behavior of the spec, even if it is wrong and unimplemented |
| 17:41 | <ptomato> | thanks! |
| 17:45 | <shu> | incorrect assertions are editorial errors, because the spec was incoherent |
| 17:45 | <shu> | now, some of them could've been implemented wrong and we need to think harder |
| 17:45 | <shu> | but if nobody implemented it wrong, fixing assertions don't need consensus imo |
| 17:46 | <ptomato> | this one is in Temporal, so I'm not sure in how far it's been implemented wrong |
| 17:47 | <ptomato> | Frank (who I don't think is in this channel?) caught it, presumably in the process of implementing it for v8 |
| 17:49 | <Domenic> | In case people have opinions on SyntaxError vs. TypeError for URLPattern, I'm currently leaning TypeError to match URL instead of SyntaxError to match RegExp. https://github.com/WICG/urlpattern/issues/74 |
| 17:52 | <ptomato> | is it fair to say that fixing something unimplementable as written, is an editorial change, while fixing something that's implementable as written, even if nonsensical, is normative? |
| 17:54 | <ptomato> | I think I have a mostly accurate understanding, but doing this as a first-timer it would be helpful if there was a clear dividing line |
| 18:27 | <ptomato> | (I guess, something something observability, in addition to the above) |
| 18:29 | <bakkot> | ptomato: if it's implementable as written I wouldn't call it nonsensical, but yes, that's the usual rule we follow |
| 18:32 | <bakkot> | (but if there's an assertion which is violated, obviously it isn't implementable) |
| 18:37 | <ptomato> | I mean, from an implementor perspective I could see changing "? Operation(...)" to "! Operation(...)" means you have to change an implementation of, roughly, bool ok = operation(...); assert(ok); to if (!operation(...)) return failure(); |
| 18:38 | <bakkot> | I'm saying I personally would regard "it's implementable but you have an assert which is violated" as "it is not implementable". |
| 19:07 | <shu> | my bar of "implemented wrong" is slightly different, i meant more like "different impls implemented it differently" |
| 19:07 | <shu> | if an implementation copied the incoherent assert and is crashing debug builds, i don't really consider that an issue |
| 22:50 | <rkirsling> | Temporal is also an interesting case of normativity since nobody's even allowed to ship it, but there's still a huge spec to battle-harden prior to landing |
| 22:52 | <rkirsling> | so "implementedness" still implies an investment of labor, but is totally separated from usual concerns of web reality |