TypeScript 3.7 Beta (devblogs.microsoft.com)

Yes, I agree. I also think that if they were starting out today, they wouldn't have either Enums or Namespaces since those features require adding runtime code (as opposed to every other TS feature which is erasable). However, when they started out, JavaScript wasn't as evolved (and it didn't look like it would evolve this much) and so they had to add a few things "on their own".

    type Direction = "up" | "down";

    const types = ['x', 'y', 'z'] as const;
    const a: typeof types[number] = 'a'; // not ok
    const b: typeof types[number] = 'z'; // ok

    const enum Directions { Up, Down, Left, Right }
    console.log(Directions.Left)
    // emits js file with console.log(2)

  const test(direction: Direction) => direction;
  test('up' as 'up');

    const dir = "up"; // TS infers type "string"
    test(dir); // error

    const dir = "up" as const;
    test(dir); // works

It just means we are at embrace & extend. And personally I can't wait to hit extinguish. Good riddance "ECMAScript".

Mostly it's a code smell though

https://en.m.wikipedia.org/wiki/Law_of_Demeter

I don't think it's bad enough to warrant introduction of new syntax sugar to make it shorter.

The problem might be that we have most likely not yet handled the edge case situation where a.b and a.b.c doesn't exist. And just want to log out the value, and print undefined if it doesn't exist.

lodash's #get solves this for us now https://lodash.com/docs#get

I see you used flow, what do you think about nominally VS structurally typed classes?

I wish though that TS would verify that the assertion functions really check the things that they claim to check. At the moment you can write

    function assertIsString(x: number | string): asserts x is string {
    }

and TS will just ignore the fact that you didn’t check anything. One shouldn’t have to introduce a giant hole in the type system just to be able to encapsulate checks that TS should be capable of understanding.

I filed this as a bug to see if the developers agree: https://github.com/microsoft/TypeScript/issues/33743

    function test(x: number | string): void {
        x.toUpperCase();
    }

    function test(x: number | string): void {
        if (typeof x === "number")
            throw new Error();
        x.toUpperCase();
    }

    function assertIsString(x: number | string): asserts x is string {
    }

    function assertIsString(x: number | string): asserts x is string {
        if (typeof x === "number")
            throw new Error();
    }

    if (typeof x === "number")
         throw new Error();

> it would be even better if TS could do this automatically like Flow though

That would imply that the same function signature could produce different type checking results at the call site. That is something I find extremely frustrating as you can no longer reason about type checking locally.

I don't get Assert Functions.

What are they good for? Maybe there is a use case I am not getting, but this

  function yell(str) {
    assert(typeof str === "string");

    return str.toUppercase();
    //         ~~~~~~~~~~~
    // error: Property 'toUppercase' does not exist on type 'string'.
    //        Did you mean 'toUpperCase'?
  }

  function assert(condition: any, msg?: string): asserts condition {
    if (!condition) {
        throw new AssertionError(msg)
    }
  }

Seems like the equivalent to

  function yell(str : String) {
    return str.toUppercase();
    //         ~~~~~~~~~~~
    // error: Property 'toUppercase' does not exist on type 'string'.
    //        Did you mean 'toUpperCase'?
  }

But the latter has much less code and is clearer too.

What am I missing?

  function something(num : number) {
    assertIsInRange(num);
  
    return num + 1;
  }
  
  function assertIsInRange(num: number, msg?: string): asserts num {
    if (num < 50 || num > 100) {
      throw new Error('not in range');
    }
  }
  
  something(50);

  if (typeof num === 'number') {
    assertIsInRange(num);
  }

  function something(num : number) {
    assertIsInRange(num);

    return num + 1;
  }

  function assertIsInRange(num: number, msg?: string): asserts num {
    if (num < 50 || num > 100) {
      throw new Error('not in range');
    }
  }

  something(50);

  function something(num) {
    assertIsInRange(num);
    return num + 1;
  }
  function assertIsInRange(num, msg) {
    if (num < 50 || num > 100) {
      throw new Error('not in range');
    }
  }
  something(50);

As an aside... I am still a huge fan of Coffeescript as my main driver. I'm learning more about TypeScript and Rust, but Coffeescript remains my language for concision/expression :)

All of the above need method chaining, though:

https://en.wikipedia.org/wiki/Method_chaining

This may feel a bit nit-picky, but they haven't been added to ECMAScript yet. There are two features here: the optional chaining operator[1] and nullish coalescing operator[2]. Both are at stage 3 of the standardization process.

Changes to proposed features can still be made at stage 3 if critical issues come up. Otherwise, once implementors have sufficient experience with them (and tests & multiple implementations exist) the proposals will be eligible to move to stage 4, after which they'll be able to be included as part of the next ECMAScript spec.

Both proposals are progressing through the process very smoothly, but I wouldn't rely on them for anything critical just yet.

[1] https://github.com/tc39/proposal-optional-chaining

[2] https://github.com/tc39/proposal-nullish-coalescing