| 16:57 | <rbuckton> | Since it is plenary week, should we assume the structs meeting is cancelled for today? |
| 16:57 | <nicolo-ribaudo> | Yes |
| 16:58 | <nicolo-ribaudo> | Unless we want to have little stage 2 party :P |
| 16:59 | <rbuckton> | I'd rather save that for the next meeting |
| 23:16 | <shu> | i talked with jordan and mark in the hallway and i think we have promising directions to explore for both of the big issue areas of:
the "can be used as weakmap keys" concern basically 100% rides on implementation feasibility from others at this point, and i don't think it's useful for this group to design around it yet |
| 23:18 | <shu> | for unsafe {}, mark is also happy with "all shared struct fields always private", then we don't need unsafe {}, because the idea is the public API must be written by the developer, which should be threadsafe the implementation constraint for me with that world is that we must be able to compile #-names in shared structs just as normal property slots. because of the "#-names have different identities depending on the evaluation of the class declaration" thing, they are wildly inefficient in engines. this problem might not exist at all if we have the restriction that struct decls are top-level only and thus can't be reevaluated anyways so that sounds like a promising thing for us to explore |
| 23:20 | <shu> | for "i want to stamp private fields", jordan is happy with an outcome where we expose a new method like preventExtensions that also prohibits any object from being stampable. mark has been independently working on a new integrity level that already has that capability, and is happy to unbundle that new method from the integrity level. so it sounds like if we just introduce that method, here or independently, that solves it. everyone AFAIK agrees return override is loathsome so that method would be a good addition independently anyway |
| 23:20 | <shu> | structs, then, would be born as if that method were already called on them |
| 23:21 | <shu> | oh, one additional caveat to the unsafe {} thing, without unsafe {}, shared arrays would just work, which is also racy. i flagged this to mark, who thinks that is actually fine and as intended, because the indexed properties are the public API of an array |
| 23:38 | <Mathieu Hofman> |
That is great news
Yeah we've been going at this from different approaches for a couple years now. In the latest iteration we were thinking of a new explicit integrity level above "freeze", but I have to think if could we lower that to an explicit integrity level right above "prevent extensions". The thing is that we wanted to attach some different proxy trap semantics as well, and provide a signal to not trigger the override mistake, and I don't know if that can work in that case.
I had independently been mulling over this, and the 2 issues I came up with are:
|