| 19:35 | <Richard Gibson> | why is WeakRef.prototype.constructor normative optional? https://tc39.es/ecma262/#sec-weak-ref.prototype.constructor |
| 19:36 | <shu> | SES IIRC? |
| 19:43 | <Richard Gibson> | how so? I could see WeakRef itself being normative optional, but what is the point of shipping a WeakRef whose prototype does not have a constructor property? |
| 19:45 | <Richard Gibson> | and I don't see discussion at https://github.com/tc39/ecma262/pull/2089 other than "we're adding inline normative optional spec text" from yulia in the PR description without further explanation |
| 19:49 | <Mathieu Hofman> | The motivation is that it can be removed so you wouldn't be able to create a new WeakRef from an instance. Aka sharing an instance to observe the liveness of one object doesn't allow you start observing the liveness of any object. |
| 19:51 | <Richard Gibson> | but why would an implementation ship that rather than requiring code to delete the property? |
| 19:52 | <Richard Gibson> | it seems bizarrely special-cased from an implementation perspective |
| 19:53 | <ljharb> | same reason an implementation would "ship" without any other normative-optional thing |
| 19:53 | <Mathieu Hofman> | The idea is that an environment without access to the contructor through the prototype would still be a compliant JavaScript environment. Aka not introduce code that expects it to be there. |
| 19:53 | <ljharb> | code that requires normative-optional things to exist isn't portable; it's reasonable for an implementation to only support portable code (where "implementation" could include "any environment that's been prepared with first-run JS code") |
| 19:54 | <Mathieu Hofman> | Richard Gibson Is there any reason you would want it to always be there? |
| 19:54 | <Mathieu Hofman> | besides the "it's different |
| 19:55 | <Richard Gibson> | to avoid the cognitive burden of an exception to the rule that every built-in constructor's prototype has a constructor property referencing it |
| 19:56 | <Richard Gibson> | delete builtInConstructor.prototype.constructor is always allowed, but only in this one case is a conforming implementation allowed to ship without the property present at all |
| 19:58 | <Mathieu Hofman> | Do you have a specific use case, or is it conceptual only ? |
| 19:58 | <Richard Gibson> | the latter |
| 19:59 | <Richard Gibson> | it's not even like it allows SES or similar to avoid the delete WeakRef.prototype.constructor code, because conforming implementations can and do ship with it |
| 20:01 | <Mathieu Hofman> | No but it means the environment SES/lockdown creates is still a fully compliant JavaScript environment |
| 20:01 | <Richard Gibson> | no, that isn't true because of the other mutations |
| 20:01 | <Richard Gibson> | Function.prototype, Date.now, Math.random, etc. |
| 20:03 | <Mathieu Hofman> | Ok, fair, it's one less difference, and we're working on mitigating the others. E.g. all those you mention are there, but they throw. Doing that on Function.prototype is ok because SES has to virtualize Function anyway. |
| 20:04 | <Richard Gibson> | an implementation that shipped with a https://tc39.es/ecma262/#sec-math.random that throws exceptions would not be conforming with https://tc39.es/ecma262/#sec-math.random |
| 20:04 | <Mathieu Hofman> | Having the spec say "this may not be there" encourages programs to not rely on it being there. |
| 20:06 | <Richard Gibson> | SES lockdown intentionally restricts the environment in ways that violate the spec; why should there be a special exception for WeakRef.prototype.constructor? |
| 20:07 | <Mathieu Hofman> | Right, I think we're trying to compare something that was there from the beginning, and something that is introduced more recently. E.g. for arrays, most original methods seem to skip over holes, but all newer ones don't. It's a difference that avoids repeating previous mistakes in light of new knowledge |
| 20:08 | <Richard Gibson> | if that were the case, then shipping it should be considered a violation. This allows for differences that are rightfully discouraged elsewhere |
| 20:10 | <Richard Gibson> | we don't permit implementations to pass holes to Array.prototype.flatMap callbacks |
| 20:12 | <Richard Gibson> | so I guess I have my answer about why the annotation is there, but the answer doesn't make sense |
| 20:15 | <Mathieu Hofman> | There is no risk in allowing the WeakRef constructor in a non-SES environment, there is in SES. And SES strives to provide a fully compatible environment. So only SES needs to remove the constructor. I assume removing it always was not an option (I wasn't around when this was decided) |
| 20:17 | <Richard Gibson> | in what sense is the SES environment "fully compatible" when it intentionally blocks execution of unsafe code that a conforming environment is required to support? |
| 20:19 | <Mathieu Hofman> | "strives to" is the operating keyword here. The idea is to stop introducing further things that SES would have to willfully break, while working on remediating the ones that currently do (the override mistake is still around) |
| 20:23 | <Richard Gibson> | doesn't SES also freeze all builtins, including new ones like WeakRef? |
| 20:25 | <Richard Gibson> | it is important for ES conformance that they be mutable, and important for SES that they not be. There's an explicit divergence there that seems to me like it has exactly the same character as deleting and overriding properties in a way that is allowed by the spec but results in an environment that does not itself conform with the necessary initial state |
| 20:35 | <Richard Gibson> | and worse, anyone who cares about restricting access to liveness information must control the global WeakRef anyway, even if the host implementation decided not to include WeakRef.prototype.constructor. There's just doesn't seem to be any benefit in shipping without it or in considering such an environment to be a valid initial state |
| 20:37 | <Mathieu Hofman> | I would like to see code which assumes WeakRef contructor to be present on the global |
| 20:48 | <shu> | i just don't see what value SES gets from claiming compliance |
| 20:48 | <shu> | if it doesn't care about interop, my position is it doesn't need to care about compliance either |
| 20:48 | <shu> | it can still strive to be mostly interoperable |
| 21:11 | <jschoi> | Does SES claim to be “compliant” with ES? Last I checked it merely claimed to be a syntactic subset with “mostly” identical semantics. Ditto for Jessie versus SES. |
| 21:12 | <shu> | if it doesn't then i am further confused why mark cares about normative optionality of things |
| 21:13 | <jschoi> | Probably wanting to maximize the “mostly” part in “mostly identical semantics”, I guess, haha. |
| 21:13 | <shu> | he can perfectly well claim that without the spec having any special allowances |
| 21:13 | <shu> | just say they're willful violations, but very few and sensible for this use case |
| 21:32 | <Michael Ficarra> | Can someone in TG2 please add a String titlecase method so I can stop having conversations like this? https://twitter.com/smooshMap/status/1461445458253860864 |
| 21:33 | <Michael Ficarra> | Richard Gibson: given you worked on Intl.Segmenter, you might be interested ^ |
| 21:44 | <jschoi> | I saw some people asking for a camel-casing method too on Discourse, for what it’s worth. |
| 21:51 | <Michael Ficarra> | jschoi: if we had titlecasing, camel casing could be implemented easily with Intl.Segmenter |
| 21:51 | <Michael Ficarra> | but we just can't implement titlecasing without UNIDATA |
| 21:57 | <Mathieu Hofman> | Richard Gibson: it sounds like we should discuss how SES requirements and JavaScript compliance interact, and if anything should be formalized. Maybe a good topic for a future SES meeting? |
| 22:05 | <bakkot> | Michael Ficarra: you should +1 https://github.com/tc39/ecma402/issues/294 if you want that |
| 22:11 | <jschoi> | but we just can't implement titlecasing without UNIDATA |
| 22:48 | <shu> | why not toTitleCaseASCII |
| 22:51 | <Michael Ficarra> | jschoi: I think what Unicode calls title case, you call capitalise words |
| 22:51 | <Michael Ficarra> | which is still quite hard to do |
| 22:55 | <jschoi> | Well, in § 5.18 (https://www.unicode.org/versions/Unicode14.0.0/ch05.pdf#page=43), the Standard refers to “titlecasing” as a process in which not all words are capitalized, e.g., “The Merry Wives of Windsor” in English and “Les joyeuses commères de Windsor” in French. |
| 23:07 | <Michael Ficarra> | jschoi: Looks like they use it in both ways
|