codehag / documenting-invariants

Proposal to document design invariants in TC39
6 stars 3 forks source link

Invariant: Primitives #12

Open ljharb opened 3 years ago

ljharb commented 3 years ago
codehag commented 2 years ago

Sorry for the late reply. What is the purpose for each listed point? Can you add the motivations of each?

ljharb commented 2 years ago

Sure, i’ll update it later today - but they’re an invariant regardless of the motivation, because they happen to be true.

codehag commented 2 years ago

hmm. The goal of this document is not to record what is currently true about the language, but what is defended. A defense should have a motivation, specifically, why something should not change.

Per the readme

Part of the work that we do at TC39 is ensuring that as the language changes, certain properties of the language remain.

but, i believe what you posted above is probably stuff that we want to protect. Part of the process with invariants will also be deprecating them when a motivation no longer holds true, so having it present is important.

Not everything here necessarily needs to be "always true". it can also be points that are upheld in committee as things that we should deprecate in our practice or not repeat. Those are also worth documenting, along with their motivation.

ljharb commented 2 years ago

The list of what invariants are defended is a subset of the broader list of invariants - we have to document the latter before we can achieve consensus on the former, no?

ljharb commented 2 years ago

I've updated the OP with some parentheticals to provide motivation.

codehag commented 2 years ago

Reading through, it seems like your concern here is around the behavior of boxing values (and testing for "primitiveness"), not the behavior of primitives themselves (which I thought was the initial goal of this post). Maybe that is the invariant you are trying to point out here? (i think i misunderstood the intention of your original post when I asked you for motivations for each.)

This might be multiple items still. It wasn't immediately clear to me what this should be (a single post or multiple).

we have to document the latter before we can achieve consensus on the former, no?

If we do this exhaustively we will have a reverse engineered copy of the specification, along with its entire error space. I think this will end up drowning out the goal here, which is to record what is not written down but is treated as though it is, namely -- why we don't want to change certain properties of the language. For example, the coercion properties you list in bullet 2 are written down (https://tc39.es/ecma262/#sec-toobject), so maybe it doesn't make sense to write that down again in isolation -- but, as part of a description of "we want to enable boxing" this makes sense as supplementary info.

codehag commented 2 years ago

I've created issue templates to hopefully make this process a bit easier.

ljharb commented 2 years ago

If i recall, i filed this issue in response to some Record and Tuple discussions.

My hope is that “things that are currently true, and ideally will forever remain so” are eventually documented such that we never change them in the future, so that arbitrary delegates don’t have to be present in order to maintain those invariants.

codehag commented 2 years ago

My hope is that “things that are currently true, and ideally will forever remain so” are eventually documented such that we never change them in the future, so that arbitrary delegates don’t have to be present in order to maintain those invariants.

thats precisely the goal here! sorry if my questions here have been frustrating. If you are happy with this being split into two parts

1) Ability to detect primitives via the object constructor when called as a function 2) Ability to box primitives

then I will go ahead and post it. Does that work ?

ljharb commented 2 years ago

Sure, sounds great!