[kilburn]

The advantage here is that you are not repeating the type of the property twice (once as optional in the base type, once as mandatory in the extended class).

Even though the code may seem inscrutable, note that the resulting type is fairly easy to understand in your IDE. That is, if you hover over the "B" to see what the type definition is, you see:

  type B = A & {
    foo: number;
    baz: number;
  }

If you defined the type like this (which is equivalent to extending the class as you were proposing) and later on someone changes the type of one such mandatory properties in the base and/or extended class without changing the other, the error becomes much much weird, on the lines of:

> Type 'number' is not assignable to type 'never'.(2322)

Here typescript is saying that a prop cannot have a value (type never) because the base class defines it as "number?" but the extended one defines it as "string", and the intersection between them is empty. This is hard to understand when it pops out where you don't expect it. Harder than ignoring the weird "Ensure" thing, seeing what it does (the resulting type B definition) and moving on.

Defining advanced types may be cumbersome, but dealing with code that uses them is still approachable. This allows the more experienced team members to "shape the ground" and less experienced members still reap the benefits even if they don't fully understand how the thing works.

[Androider]

The beginner programmer copies the property definition.

The advanced programmer simply writes "type Ensure<T, K extends keyof T> = T & { [U in keyof Pick<T, K>]-?: T[U] };", thus removing the need to copy the property.

The master programmer copies the property definition.

[goto11]

Consider it in the context of a framework like React. The type of setState() is defined as Partial<State>. The framework cannot just copy paste the type definition with properties set to optional, since the state type is defined by the user and specific for each component. Without type helpers there would be no way for a framework to define the type for setState().

I'm not sure how often you would need type helpers in application code, for frameworks and libraries they are a godsend.

Your argument is a bit like saying we don't need parameterized types like Array<T> because you can just copy paste the code for each type.

[kilburn]

Do you have some argument? Without arguments, your comment has as much substance as me replying:

The beginner programmer copy/pastes the code.

The advanced programmer writes a function, thus removing the need to maintain copies of the code.

The master programmer copy/pastes the code.

It is not like "Ensure" would be a single-use thing. "Ensure" here is a utility type definition, which is what a "function in the world of types" would be.

[kbenson]

I think they're going for a "The Codeless Code"[1] type of koan. The idea is to express through something that may seem slightly illogical or counterintuitive an insight.

> Without arguments, your comment has as much substance as me replying:

Yes, what you substituted is equivalent, and they likely could have written that to the exact same effect.

> It is not like "Ensure" would be a single-use thing. "Ensure" here is a utility type definition, which is what a "function in the world of types" would be.

There's a few ways to interpret the stanza. The way I interpreted it is that the beginner uses a library to provide the definitions, the advanced programmer just writes their own definitions inline as needed, and the master programmer uses a library for the definitions they need (whether written by themself or someone else).

In that respect, I think you're both in agreement.

For what it's worth, I think comments like these are generally beneficial, if maybe I prefer at least a line of context. That they can be interpreted differently and may require a bit of thought to map onto the current context can sometimes allow people to view their beliefs from a slight remove where more introspection is possible, or spur interesting tangents to explore. Both of those are generally beneficial in a forum like this, IMO.

1: http://thecodelesscode.com/contents