Usage for (deep) readonly and object freeze

[plehnen]

When I read the proposal, my first thought was: I want to abuse this to get rid of my typescript deep-readonly problems, where the type is not easy to get rid of those "readonly" flags when I clone it.

If this Composite object would be deeply immutable (readonly or frozen) and would have an "extract" function like Composite.extract(Composite({ ...})) which returns a deep clone which is mutable, that would be sooo nice!
Especially if it would play along with TypeScript, being of type Composite<T> and the .extract would become T.

[Maxdamantus]

Especially if it would play along with TypeScript, being of type Composite<T> and the .extract would become T.

I don't think this would work as cleanly as you'd like. In theory you could achieve type symmetry in this hypothetical extract function, but at the expense of making the Composite constructor asymmetrical.

Presumably what you're wanting is this:

declare function Composite<T>(o: T): Composite<T>;
declare function extract<T>(c: Composite<T>): T;

But these types are not logically consistent, as demonstrated here ("wanted" is what I think you're expecting, and "actual" is the actual type according to the above declarations):

// wanted: Composite<{}>
// actual: Composite<{}>
const a = Composite({});
// wanted: Composite<{ a: {} }>
// actual: Composite<{ a: Composite<{}> }>
const b = Composite({ a });
// wanted: { a: {} }
// actual: { a: Composite<{}> }
const c = Composite.extract(b);

To get something logically consistent, one of the functions (either the Composite constructor or the extract function) needs to be asymmetrical WRT its type parameter, so you have either this:

declare function Composite<T>(o: T): Composite<T>;
declare function extract<T>(c: Composite<T>): Decompose<T>;

or this:

declare function Composite<T>(o: T): Composite<Decompose<T>>;
declare function extract<T>(c: Composite<T>): T;

where the Decompose type-level function recursively turns Composite<U> types into U.

I strongly think the former should be favoured over the latter. For one it allows composing plain non-composite objects while the latter restricts these uses (probably by throwing, since I believe tc39 has ruled out new automatic conversions), but overall the typing is conceptually simpler.

The extract function can still exist given the current proposal, but it wouldn't return a T given a Composite<T> (rather something like Decompose<T> as above). You'd likely need this recursive type application whenever you have the concept of "deep X". This proposal avoids such a concept, so the typing pattern would be restricted to the extract function which does use the concept.

Also note that the extract function can always be implemented as a library (without requiring deep immutability). I usually have general anti-pattern concerns when applying "deep X" concepts to generic parameters, including this one, but maybe if it ends up being useful it could be standardised later?