Deno: Remove null from the source code

[yordis]

Instead of using null just use underfined in the source code.

This would lead change in the type system that will benefit as as well. Typescript use ? for mark something optional (undefined).

Thoughts?

[kitsonk]

Actually the type system considers null and undefined both valid optional properties. Is there any other compelling reason to use undefined over null?

[ry]

Like where for example? Is this a TS best practice?

[givehug]

https://github.com/Microsoft/TypeScript/wiki/Coding-guidelines#null-and-undefined

Use undefined. Do not use null.

undefined more convenient for type checking

[yordis]

https://www.typescriptlang.org/docs/handbook/functions.html#optional-and-default-parameters

In JavaScript, every parameter is optional, and users may leave them off as they see fit. When they do, their value is undefined. We can get this functionality in TypeScript by adding a ? to the end of parameters we want to be optional. For example, let’s say we want the last name parameter from above to be optional:

@kitsonk ? on Typescript is undefined but not null.

@ry there is no best practices in Javascript ecosystem mate unless you just decide to pick the most popular one as @givehug suggested, Microsoft uses undefined all the time.

I am just tying to avoid this https://github.com/ry/deno/pull/209/files#r194254299

He used ? but checks for null, this is the reason why I would ban it all together. Less errors.

[monkingxue]

@givehug But I found STOP READING IMMEDIATELY at the beginning of the wiki, and I think null and undefined is both ok, they have different semantic.

[yordis]

@monkingxue Did you read why they added that?

Also @ry if we will use it then at least lets create some generic types that would mimic the source code.

From your comment

x == null is often used to testing against both null and undefined.
tslint makes exceptions for triple equals in this case.

The type system doesn't see it that way but you have a valid point so I would suggest to create something like.

type Nullable<T> = T | null;
type Maybe<T> = T | null;  // haskell-ish
type Optional<T> = Nullable<T> | undefined; // better name are welcome

Reading from the official documentation.

http://www.typescriptlang.org/docs/handbook/advanced-types.html

Optional parameters and properties
With --strictNullChecks, an optional parameter automatically adds | undefined:

class C {
    a: number;
    b?: number;
}
let c = new C();
c.a = 12;
c.a = undefined; // error, 'undefined' is not assignable to 'number'
c.b = 13;
c.b = undefined; // ok
c.b = null; // error, 'null' is not assignable to 'number | undefined'

this c.b = null; // error, 'null' is not assignable to 'number | undefined' fails which basically means ? doesn't include null Related to https://github.com/ry/deno/pull/209#discussion_r194254299

[givehug]

@monkingxue, yes those are coding guidelines for TS contributors. But it has some point in it. Anyway it would be nice if it was consistent throughout the project whichever option is used.

[yordis]

From: http://www.typescriptlang.org/docs/handbook/advanced-types.html

Type guards and type assertions

Since nullable types are implemented with a union, you need to use a type guard to get rid of the null. Fortunately, this is the same code you’d write in JavaScript:

function f(sn: string | null): string {
    if (sn == null) {
        return "default";
    }
    else {
        return sn;
    }
}

The null elimination is pretty obvious here, but you can use terser operators too:

function f(sn: string | null): string {
    return sn || "default";
}

In cases where the compiler can’t eliminate null or undefined, you can use the type assertion operator to manually remove them. The syntax is postfix !: identifier! removes null and undefined from the type of identifier:

function broken(name: string | null): string {
  function postfix(epithet: string) {
    return name.charAt(0) + '.  the ' + epithet; // error, 'name' is possibly null
  }
  name = name || "Bob";
  return postfix("great");
}

function fixed(name: string | null): string {
  function postfix(epithet: string) {
    return name!.charAt(0) + '.  the ' + epithet; // ok
  }
  name = name || "Bob";
  return postfix("great");
}

[monkingxue]

@givehug Yeah I read the post but I just find This is NOT a prescriptive guideline for the TypeScript community.
I think if we use ? operator, the undefined is a better choice, but it doesn't mean we should replace all null to undefined.

[joelday]

IMO, it should just stick to the language and the v8 runtime as is. Basically, if it involves a patch to the TypeScript language service and compiler or lib d.ts files, it's out of scope.

[kitsonk]

I have worked with the TypeScript team quite closely. I can tell you for certain that they do not intend that code styling to be taken as guidance for authoring downstream code. Both Daniel and Mohammed have twitches when people use that for commenting on other styles. The point from the TypeScript team, or any team, is that a consistent convention is the most important thing. The TypeScript team have gone out of their way to support both equally.

While I personally have not used null, and especially loose comparison, that does not mean it is invalid. Loose comparisons _can_ lead to confusion at times, but that again is still preference. Consistency is more important.

[yordis]

Just for be clear about it undefined !== null while I wouldn’t mind people to use null just do not use ? because from Typescript perspective is wrong, as the programming language says ? doesn’t include null which is the reason why I suggest to add a global type for nullable types.

[ry]

@joelday I agree strongly.

I'm okay with testing null and using ?. This is a trivial matter anyway. Let's not continue the discussion.