We should talk about this in the next design meeting though.

Is there any way filter out just the required properties or just the optional properties?

I've been trying to make a type mapping that does this with no luck so far.

@yortus Something like this:

type OptionalPropNames<T> = { [P in keyof T]: undefined extends T[P] ? P : never }[keyof T];
type RequiredPropNames<T> = { [P in keyof T]: undefined extends T[P] ? never : P }[keyof T];
type OptionalProps<T> = { [P in OptionalPropNames<T>]: T[P] };
type RequiredProps<T> = { [P in RequiredPropNames<T>]: T[P] };
type Foo = {
    a: string;
    b: number;
    c?: string;
    d?: number;
}
type T1 = RequiredProps<Foo>;  // { a: string, b: number }
type T2 = OptionalProps<Foo>;  // { c?: string | undefined, d?: number | undefined }

Strictly speaking this doesn't filter on optional vs. required, but rather whether undefined is assignable to the property or not. But given that required properties rarely if ever have undefined as a permitted value, it's largely the same.

i salute the idea, but somehow this syntax doesn't seem scalable

@ahejlsberg thanks, that's just what I need.

@Aleksey-Bykov the syntax makes me uncomfortable too. TypeScript is steadily building up really useful full compile-time programming capabilities, but some of the syntax seems very specific to a few cases (e.g. this PR). Having a few highly orthogonal compile-time programming constructs that also covered these special cases would be ideal. But I'm sure that's much easier said than done.

on a constructive note, at some point when there are over 10 different modifiers at play we gonna need some meta syntax to control them, something like this, forgive my french:

{
     [{ // <--- sort of attribute syntax of C#?
           amIReadonly: true || shouldIBeSomethingElse,
           canBeUndefined: canBePossiblyUndefined && thereIsNoHope
     }]
     value: number
}

or something like Object.defineProperty

to extend this idea to mapped or nested types by making a set modifiers a function of the previous/higher set of modifiers

{
     [before => ({
           isReadonly: !before.isReadonly,
           canBeUndefined: true
     })]
     value: number
}

These look good to me, and I'm actually pretty OK with the syntax. If something better were suggested, sure, but I'd be comfortable/happy with using this one.

As for @Aleksey-Bykov suggestions, compile-time, type-domain functions in general would be a really useful thing to have. Conditional types get us a big step closer to that, but we still aren't there. This might be a nice place to start.

I think we're making big strides forward. With the pattern matching and recursion, I got a bunch of types to work that just hadn't been possible before (e.g. setting/removing readonly/? recursively in nested structures, flattening promises/arrays).