Typescript: Suggestion: non-nullable type

I suggest using a type other than string as an example since it by nature is nullable. :P
I can perceive non-nullable types being problematic since the user and compiler of "!" expects the type to always be non-null, which can never be truly asserted in JavaScript. A user might define something like this:

function(myNonNull:!myClass):void {
  myNonNull.foo();
}

And because it's defined as non-null, everything might be happy for the compiler, but then someone else who uses it in javascript passes something null and kaboom.

Now that said, maybe the solution could be that for public facing methods, it could automatically assert not null. But then the compiler could also assert that you cannot have public properties (or private for that matter really) that can have a !nonnull declaration since they could not be enforced.

This may go deeper into the discussion of code contracts for this to be properly enforced.

Forgive my critics, I think there is very little need in non-nullable types if/as-soon-as algebraic data types are here. The reason people use null to represent a missing value is because there is no better way to do that in JavaScript and in most OOP languages alike. So imaging ADTs are already here. Then, as for the old libs written before non-nullables, having them won't make life any better. As for the new libs, with ADT's in place one can very accurately model what a value can take according to the business domain specification without using nulls at all. So I guess what I am saying is that ADT is way more powerful tool to address the same problem.

Personally, I just wrote a little Maybe<T> interface and use discipline to ensure that variables of that type are never null.

I suggest using a type other than string as an example since it by nature is nullable. :P
I can perceive non-nullable types being problematic since the user and compiler of "!" expects the type to always be non-null, which can never be truly asserted in JavaScript. A user might define something like this:

function(myNonNull:!myClass):void {
myNonNull.foo();
}
And because it's defined as non-null, everything might be happy for the compiler, but then someone else who uses it in javascript passes something null and kaboom.

I don't really understand you can also define :

function myFunc(str: string): int {
 return str && str.length;
}

and if someone pass an int to that function it will ends up with an error also, an advantage of typescript is to delegate to the compiler pass things that you would check manually in javascript, having another check for nullable/non-nullable type seems reasonable for me. By the way SaferTypeScript and ClosureCompiler already do that sort of check.

With union types, we could have a pretty simpler specification for that.
Let's say we have now a basic type 'null', we can have a 'stricter' mode where 'null' and 'undefined' is not compatible with any type, so if we want to express a nullable value we would do :

var myNullableString: (null | string);
var myString = "hello";
myNullableString = myString //valid
myString = myNullableString // error null is not assignable to string;

With the 'strict mode' activated typescript should check that every variable non nullable is initialized, also by default optional parameter are nullable.

var myString: string; // error
var myNullableString: (null | string); // no error

function myString(param1: string, param2?: string) {
  // param1 is string
  // param2 is (null | string)
}

@fdecampredon +1

IIRC from what Facebook showed of Flow which is using TypeScript syntax but with non-nullable types by default they support a shorthand for (null | T) as in your original post - I think it was ?T or T?.

var myString: string; // error

That could potentially be quite annoying in the case where you want to initialize a variable conditionally, eg.:

var myString: string;
if (x) {
myString = a;
} else if (y) {
myString = b;
} else {
myString = c;
}

In Rust for example, this is fine as long as the compiler can see that myString will get initialized before it is used but TypeScript's inference doesn't support this at the moment.

Honestly doing something like var myString = '' instead of var myString: string does not bother me so much, but sure that kind of rule is always possible.

@fdecampredon +1 for this - I like the idea very much. For code bases that are 100% JavaScript this would be a useful compile-time only constraint. (As I understand your proposal there's no intention for generated code to enforce this?)

As for shorthand for (null | string) sure ?string is fine.
And sure @johnnyreilly it's only a compile time check

Sum types make non-nullable types by default a very interesting possibility. The safety properties of non-nullable by default can't be overstated. Sum types plus the planned "if/typeof destructuring" (not sure what this should be called) even make it type safe to integrate nullable and non-nullable APIs.

However, making types non-nullable by default is a huge breaking change, which would require changing almost every existing third-party type definition file. While I am 100% for the breaking change, no one person is able to update the type definitions that are out there in the wild.

It's good that a great consensus of these definitions are collected in the DefinitelyTyped repo, but I still have practical concerns about this feature.

@samwgoldman the idea is to have non-nullable types only under a special compiler flag like nonImplicitAny this flag could be named strict or nonNullableType. So there would be no breaking changes.

@fdecampredon What about the type definitions for non-TypeScript libraries, like those at DefinitelyTyped? Those definitions are not checked by the compiler, so any 3rd party code that could return null would need to be re-annotated in order to work correctly.

I can imagine a type definition for a function that is currently annotated as "returns string," but sometimes returns null. If I depended on that function in my nonNullableType'ed code, the compiler doesn't complain (how could it?) and my code is no longer null-safe.

Unless I'm missing something, I don't think this is functionality that can be turned on and off with a flag. It seems to me that this is an all-or-nothing semantic change to ensure interoperability. I would be happy to be proven wrong, though, because I think a flag-switched feature is more likely to happen.

As an aside, there isn't much information available yet on Facebook's Flow compiler, but from the video recording of the presentation, it seems like they went with non-nullable by default. If so, at least there is some precedence here.

Ok let's assume there is a shorthand ? type for type | null | undefined.

@fdecampredon What about the type definitions for non-TypeScript libraries, like those at DefinitelyTyped? Those definitions are not checked by the compiler, so any 3rd party code that could return null would need to be re-annotated in order to work correctly.

I can imagine a type definition for a function that is currently annotated as "returns string," but sometimes returns null. If I depended on that function in my nonNullableType'ed code, the compiler doesn't complain (how could it?) and my code is no longer null-safe.

I don't see the problem, sure some definition files won't be valid with the nonNullableType mode, but most of the time good library avoid to return null or undefined so the definition will still be correct with majority of the cases.
Anyway I personally rarely can pick a DefinitelyTyped definition without having to check/modify it you'll just have a little bit of extra work to add a ? prefix with some definitions.

Unless I'm missing something, I don't think this is functionality that can be turned on and off with a flag. It seems to me that this is an all-or-nothing semantic change to ensure interoperability. I would be happy to be proven wrong, though, because I think a flag-switched feature is more likely to happen.

I don't see why we could not have a flag switched feature, the rules would be simple :

• in normal mode ? string is equivalent to string and null or undefined are assignable to all the types
• in nonNullableType mode ? string is equivalent to string | null | undefined and null or undefined are not assignable to any other type than null or undefined

Where is the incompatibility with a flag-switched feature ?

Flags that change the semantics of a language are a dangerous thing. One problem is that the effects are potentially very non-local:

function fn(x: string): number;
function fn(x: number|null): string;

function foo() {
    return fn(null);
}

var x = foo(); // x: number or x: string?

It's important that someone looking at a piece of code can "follow along" with the type system and understand the inferences that are being made. If we starting having a bunch of flags that change the rules of the language, this becomes impossible.

The only safe sort of thing to do is to keep the semantics of assignability the same and change what's an error vs what isn't depending on a flag, much like how noImplicitAny works today.

I know it would break retro-compatibility, an I understand @RyanCavanaugh point of view, but after tasting that with flowtype it is honestly really an invaluable feature, I hope it will ends up being a part of typescript

In addition to RyanCavanaugh's comment --> From what I read somewhere, the ES7 specification / proposal mention the use of function overloading (Same function name but different input parameter datatype). That is a very sorely needed feature for Javascript.

From the flow docs:

Flow considers null to be a distinct value that is not part of any other type

var o = null;
print(o.x); // Error: Property cannot be accessed on possibly null value

Any type T can be made to include null (and the related value undefined) by writing ?T

var o: ?string = null;
print(o.length); // Error: Property cannot be accessed on possibly null or undefined value

[Flow] understands the effects of some dynamic type tests

(i.e. in TS lingo understands type guards)

var o: ?string = null;
if (o == null) {
  o = 'hello';
}
print(o.length); // Okay, because of the null check

Limitations

• Checks on object properties are limited because of the possibility of aliasing:

In addition to being able to adjust types of local variables, Flow can sometimes also adjust types of object properties, especially when there are no intermediate operations between a check and a use. In general, though, aliasing of objects limits the scope of this form of reasoning, since a check on an object property may be invalidated by a write to that property through an alias, and it is difficult for a static analysis to track aliases precisely

• Type guard-style checks can be redundant for object properties.

[D]on't expect a nullable field to be recognized as non-null in some method because a null check is performed in some other method in your code, even when it is clear to you that the null check is sufficient for safety at run time (say, because you know that calls to the former method always follow calls to the latter method).

• undefined is not checked.

Undefined values, just like null, can cause issues too. Unfortunately, undefined values are ubiquitous in JavaScript and it is hard to avoid them without severely affecting the usability of the language. For example, arrays can have holes for elements; object properties can be dynamically added and removed. Flow makes a tradeoff in this case: it detects undefined local variables and return values, but ignores the possibility of undefined resulting from object property and array element accesses

What if the option is added at the same time when introducing the null type (and the questionmark shorthand)? The presence of a null type in a file would force the compiler into non-nullable mode for that file even if the flag is not present at the command line. Or is that a bit too magical?

@jbondc seems good. however the problem with that is that it will ends up with ! everywhere :p

It's tempting to want to change JavaScript but the reality is a 'string' is nullable or can be undefined.

What does this mean? There are no static types in js. So, yes, strings are "nullable", but let's not forget that they are also numberable and objectable and fooable, etc. Any value can have any type.

So when layering a static type system on top of javascript, choosing whether static types are nullable or not is just a design decision. It seems to me non-nullable types are a better default, because it's usually only in special cases that you want a function signature, for instance, to accept a null value in addition to the type specified.

Directives like "use strict" that cause scoped changes to semantics are already a part of the language; I think it would be reasonable to have a "use nonnullable types" directive in TypeScript.

@metaweta I don't think it's enough, for example what happens if a _non null module_ consume a nullable one :

//module A
export function getData(): string[] {
  return null;
}
//module B
'use nonnull'
import A = require('./A');

var data: string[] = A.getData();

data in module B is in fact nullable, but since 'use nonnull' was not used in module A should we report an error ?
I don't see a way to solve that problem with directive based feature.

Yes,

var data: string[] = A.getData();

would cause an error. Instead, you'd have to provide a default value for when getData() returns null:

var data: string[] = A.getData() || [];

@metaweta ok but how do you know that it's an error ? :)
type of getData is still '() => string[]' would you automaticly treat everything that comes from a 'nullable module' as 'nullable ' ?

Yes, exactly (unless a type from the nullable module is explicitly marked otherwise).

That sounds like you now want a per file flag that dictates whether of not that file defaults to nullable or not.

Personally I think it's a bit late to introduce this change, and @RyanCavanaugh is right, the change would make Typescript less predictable as you would not be able to determine what was going on just by looking at a file.

Do projects start with this compiler flag on or off by default? If someone is working on a no default nullable project and create / switch to a default nullable one will that cause confusion?
I currently work with No Implicit Any in most of my projects, and whenever I come across a project that doesn't have that option turned on it takes me by surprise.

The no impicit any is good, but in terms of flags that change the way the language behaves, I think that should be the line. Any more than that and people who are working on multiple projects started by different people with different rules are going to lose a lot of productivity due to false assumptions and slip ups.

@RyanCavanaugh was concerned about non-locality, and directives are lexically scoped. You can't get any more local unless you annotate each site. I'm not particularly in favor of the directive; I was just pointing out that the option exists and that it's at least as reasonable as "use strict" in ES5. I'm personally in favor of non-nullable types by default, but practically, it's too late for that. Given those constraints, I'm in favor of using ! somehow. @jbondc 's proposal lets you distinguish null from undefined; given that Java backends continue to make people use both values, it seems the most useful to me.

I'm sorry if I wasn't clear, I was both agreeing with Ryan and adding my own concerns.

Honestly if adding use not-null is the price for avoiding all the null pointer exception I would pay it without any problem, considering null or undefined as assignable to any type is the worse error that typescript made in my opinion.

@jbondc I have not used 'use strict' and am therefore making some assumptions, please correct me if my assumptions are wrong:

Not null does not affect the syntax that the programmer writes, but the capabilities of the next programmer that tries to use that code (assuming that creator and user are separate people).

So the code:

function myfoo (mynumber: number) {
    return !!mynumber;
} 

(typing on a phone so may be wrong)
Is valid code in both a normal project and a notnull project. The only way that the coder would know whether or not the code is working is if they look at the command line arguments.

At work we have a testing project (which includes prototyping new features) and a main project (with our actual code). When the prototypes are ready to be moved from one project to another (typically with large refractors), there would be no errors in the code, but errors in the use of the code. This behaviour is different to no implicit any and use strict which both would error immediately.

Now I have a fair amount of sway in these projects, so I can warn the people in charge to not use this new 'feature' because it wouldn't save time, but I don't have that capacity over all of the projects at work.
If we want to enable this feature in even one project, then we have to enable it in all of our other projects because we have a very significant amount of code sharing and code migration between projects, and this 'feature' would cause us a lot of time going back and 'fixing' functions that were already finished.

Right @jbondc. @Griffork: Sorry I didn't catch that misunderstanding; a directive is a literal string expression that appears as the first line of a program production or function production and its effects are scoped to that production.

"use not-null";
// All types in this program production (essentially a single file) are not null

versus

function f(n: number) {
  "use not-null";
  // n is not null and local variables are not null
  function g(s: string) {
    // s is not null because g is defined in the scope of f
    return s.length;
  }
  return n.toFixed(2);
}

function h(n: number) {
  // n may be null
  if (n) { return n.toFixed(3); }
  else { return null; }
}

Non-nullable types are useless. Non-nullable types are useles. They are useless. Useless! You don't realize it, but you don't really need them. There is very little sense in restricting yourself by proclaiming that from now on we are not going to be using NULL's. How would you represent a missing value, for example in a situation when you are trying to find a substring that is not there? Not being able to express a missing value (what NULL does now for now) isn't going to solve your problem. You will trade a harsh world with NULL's everywhere for equally harsh one with no missing values at all. What you really need is called algebraic data types that (among many other cool things) feature the ability to represent a missing value (what you are looking for in the first place and what is represented by NULL in imperative world). I am strongly against adding non-nullables to the language, because it looks like useless syntactic/semantic trash that is a naive and awkward solution to a well-known problem. Please read about Optionals in F# and Maybe in Haskell as well as variants (aka tagged unions, discriminated unions) and pattern matching.

@aleksey-bykov It sounds like you're unaware that JavaScript has two nullish values, undefined and null. The null value in JavaScript is only returned on a non-matching regexp and when serializing a date in JSON. The only reason it's in the language at all was for interaction with Java applets. Variables that have been declared but not initialized are undefined, not null. Missing properties on an object return undefined, not null. If you explicitly want to have undefined be a valid value, then you can test propName in obj. If you want to check whether a property exists on the object itself rather than if it's inherited, use obj.hasOwnProperty(propName). Missing substrings return -1: 'abc'.indexOf('d') === -1.

In Haskell, Maybe is useful precisely because there's no universal subtype. Haskell's bottom type represents non-termination, not a universal subtype. I agree that algebraic data types are needed, but if I want a tree labeled by integers, I want every node to have an integer, not null or undefined. If I want those, I'll use a tree labeled by Maybe int or a zipper.

If we adopt a "use not-null" directive, I'd also like "use not-void" (neither null nor undefined).

If you want to guarantee your own code from nulls just prohibit the null
literals. It's way easier than developing non-nullable types. Undefined is a
little bit more complicated, but if you know what they are coming from then
you know how to avoid them. Bottom in Haskell is invaluable! I wish
JavaScript (TypeScript) had a global super type without a value. I miss it
badly when I need to throw in an expression. I've been using TypeScript
since v 0.8 and never used nulls let alone had a need for them. Just ignore
them like you do with any other useless language feature like with
statement.

@aleksey-bykov If I'm writing a library and want to guarantee that inputs are not null, I have to do runtime tests for it everywhere. I want compile-time tests for it, it's not hard to provide, and both Closure and Flow provide support for non-null/undefined types.

@metaweta, you cannot guarantee yourself from nulls. Before your code is compiled there is a gazillion ways to make your lib cry: pleaseNonNullablesNumbersOnly(<any> null). After compiled to js there are no rules at all. Secondly, why would you care? Say it loud and clear upfront nulls are not supported, you put a null you will get a crash, like a disclaimer, you cannot guarantee yourself from all sort of people out there, but you can outline of your scope of responsibilities. Thirdly, I can hardly think of a major mainstream lib that is bulletproof to whatever user may put as input, yet it is still crazy popular. So is your effort worth troubles?

@aleksey-bykov If my library's clients are also type-checked, then I certainly can guarantee I won't get a null. That's the whole point of TypeScript. By your reasoning, there's no need for types at all: just "say loud and clear" in your documentation what the expected type is.

Off topic, nulls are extremely valuable for us because checking them is faster than checking against undefined.
While we don't use them everywhere, we try to use them where possible to represent uninitialised values and missing numbers.

On topic:
We've never had an issue with nulls 'escaping' into other code, but we have had issues with random undefinedes or NaNs appearing. I believe that careful code management is better than a flag in this scenario.

However, for library typings it would be nice to have the redundant type null so that we can choose to annotate functions that can return null (this should not be enforced by the compiler, but by coding practices).

@metaweta, by my reasoning your clients should not use nulls in their code base, it's not that hard, do a full search for null (case sensitive, whole word) and delete all of them. Too clunky? Add a compiler switch --noNullLiteral for fanciness. Everything else stays intact, same code, no worries, way lighter solution with minimal footprint. Back to my point, suppose your non-nullable types found their way to TS and avialable in 2 different flavors:

• one can use ! syntax to denote a type that cannot take a null, for example string! cannot take a null
• noNullsAllowed switch is on

then you get a piece of json from your server over ajax with nulls everywhere, moral: the dynamic nature of javascript cannot be fixed by a type annotation on top of it

@aleksey-bykov By the same token, if I'm expecting an object with a numeric property x and I get {"x":"foo"} from the server, the type system won't be able to prevent it. That's necessarily a runtime error and an inescapable problem when using something other than TypeScript on the server.

If, however, the server is written in TypeScript and running on node, then it can be transpiled in the presence of a .d.ts file for my front end code and the type checking will guarantee that the server will never send JSON with nulls in it or an object whose x property is not a number.

@metaweta, non-nullable types sure would be another type safety measure, I am no questioning that, I am saying that by imposing some very basic discipline (avoiding null literals in your code) you can eliminate 90% of your problems without asking for any help from the compiler. Well, even if you have enough resources to enforce this measure, then you still won't be able to eliminate the rest 10% of the problems. So what is the question after all? I ask: do we really need it that bad? I don't, I learned how to live without nulls successfully (ask me how), I don't remember when I got a null reference exception last time (besides in data from our server). There are way cooler stuff I wish we had. This particular one is so insignificant.

Yes we do need this badly. See The billion dollar mistake by Hoare. The null pointer exception (NPE) is the most common error encountered in typed programming languages that don't discriminate nullable from non-nullable types. Its so common that Java 8 added Optional in a desperate attempt to battle it.

Modelling nullables in the type system is not just a theoretical concern, its a huge improvement. Even if you take great care to avoid nulls in your code, the libraries you use might not and therefore its useful to be able to model their data properly with the type system.

Now that there are unions and type guards in TS, the type system is powerful enough to do this. The question is whether it can be done in a backward-compatible way. Personally I feel that this feature is important enough for TypeScript 2.0 to be backwards-incompatible in this regard.

Implementing this feature properly is likely to point to code that is already broken rather than break existing code: it will simply point to the functions that leak nulls outside them (most likely unintentionally) or classes that don't properly initialize their members (this part is harder as the type system may need to make allowance for member values to be initialized in the constructors).

This is not about _not using_ nulls. Its about properly modelling all the types involved. Infact this feature would allow the use of nulls in a safe way - there would be no reason to avoid them anymore! The end result would be very similar to pattern matching on an algebraic Maybe type (except it would be done with an if check rather than a case expression)

And this isn't just about null literals. null and undefined are structurally the same (afaik there are no functions/operators that work on one but not the other) therefore they could be modelled sufficiently well with a single null type in TS.

@metaweta,

The null value in JavaScript is only returned on a non-matching regexp and when serializing a date in JSON.

Not true at all.

• Interaction with the DOM produces null:

  console.log(window.document.getElementById('nonExistentElement')); // null

• As @aleksey-bykov pointed out above, ajax operations can return null. In fact undefined is not a valid JSON value:

 JSON.parse(undefined); // error
 JSON.parse(null); // okay
 JSON.stringify({ "foo" : undefined}); // "{}"
 JSON.stringify({ "foo" : null}); // '{"foo":null}'

NB: We can pretend that undefined is returned via ajax, because accessing a non-existent property will result in undefined - which is why undefined is not serialised.

If, however, the server is written in TypeScript and running on node, then it can be transpiled in the presence of a .d.ts file for my front end code and the type checking will guarantee that the server will never send JSON with nulls in it or an object whose x property is not a number.

This is not entirely correct. Even if the server is written in TypeScipt, one can in no way guarantee nulls from being introduced without checking every single property of every single object obtained from persistent storage.

I kind of agree with @aleksey-bykov on this. While it would be absolutely brilliant if we can have TypeScript alert us at compile time about errors introduced by null and undefined, I fear it will only induce a false sense of confidence and end up catching trivia while the real sources of null go undetected.

Even if the server is written in TypeScipt, one can in no way guarantee nulls from being introduced without checking every single property of every single object obtained from persistent storage.

This is in fact an argument _for_ non-nullable types. If your storage can return null Foo's, then the type of the object retrieved from that storage is Nullable<Foo>, not Foo. If you then have a function that returns that is meant to return Foo, then you _have_ to take responsibility by handling the null (either you cast it because you know better or you check for null).

If you didn't have non-nullable types you would not necessarily think to check for null when returning the stored object.

I fear it will only induce a false sense of confidence and end up catching trivia while the real sources of null go undetected.

What sort of non-trivia do you think non-nullable types will miss?

This is not entirely correct. Even if the server is written in TypeScipt, one can in no way guarantee nulls from being introduced without checking every single property of every single object obtained from persistent storage.

If the persistent storage supports typed data, then there would be no need. But even if that weren't the case, you'd have checks only at the data fetching points and then have a guarantee throughout _all_ of your other code.

I kind of agree with @aleksey-bykov on this. While it would be absolutely brilliant if we can have TypeScript alert us at compile time about errors introduced by null and undefined, I fear it will only induce a false sense of confidence and end up catching trivia while the real sources of null go undetected.

Using nullable types wouldn't be an absolute requirement. If you feel that its unnecessary to model the cases where a method returns null as they're "insignificant", you could just not use a nullable type in that type definition (and get the same unsafety as always). But there is no reason to think that this approach will fail - there are examples of languages that have successfully implemented it already (e.g. Kotlin by JetBrains)

@aleksey-bykov Honestly you got it completely wrong, one of the best thing about non-nullable types is _the possibility to express a type as nullable_.
With your strategy of never using null to prevent null pointer error you completely loose the possibility of using null out of the fear of introducing error, that's completely silly.

Another thing please in a discussion about a language feature don't go with stupid comments like :

Non-nullable types are useless. Non-nullable types are useles. They are useless. Useless! You don't realize it, but you don't really need them.

That just make me feel like I should ignore whatever you will ever post anywhere on the web, we are here to discuss about a feature, I can understand and gladly accept that your point of view is not mine, but don't behave like a kid.

I am not against introducing non-null type annotation at all. It has been shown to be useful in C# and other languages.

The OP has changed the course of the discussion with the following:

Honestly if adding use not-null is the price for avoiding all the null pointer exception I would pay it without any problem, considering null or undefined as assignable to any type is the worse error that typescript made in my opinion.

I was merely pointing out the prevalence of null and undefined in the wild.

I should also add that one of the things that I truly appreciate about TypeScript is the laissez-faire attitude of the language. It has been a breath of fresh air.

Insisting that types are non-nullable by default goes against the grain of that spirit.

I've been seeing a number of arguments floating around as to why we do / don't need this and I want to see if I understand all of the underlying cases that have been discussed such far:

1) want to know whether or not a function can return null (caused by it's execution pattern, not it's typing).
2) want to know if a value can be null.
3) want to know if a data object can contain null values.

Now, there are only two cases in which situation 2 can occur: of you're using nulls or if a function returns a null. If you eliminate all nulls from your code (assuming that you don't want them) then really situation 2 can only occur as a result of situation 1.

Situation 1 I think is best solved by annotating the function's return type to show presence of a null value. _This does not mean that you need a non null type_. You can annotate the function (for example by using union types) and not have non null types, it's just like documentation, but probably clearer in this case.

Solution 2 is also solved by this.

This allows programmers working at their company to use processes and standards to enforce that null types are marked up, and not the Typescript team (exactly the same way that the whole typing system is an opt-in so would the explicit nullable types be an opt in).

As for scenario 3, the contract between the server and the client is not for Typescript to enforce, being able to mark-up the affected values as possibly null might be an improvement, but eventually you'll get the same garentee from that as typescript's tooling gives you on every other value (which is to say, none unless you have good coding standards or practices!

(posting from phone, sorry for errors)

@fdecampredon, it's not the fear in the first place, it's that using null is unnecessary. I don't need them. As a nice bonus I got a problem of null reference exceptions eliminated. How is it all possible? By employing a sum-type with an empty case. Sum-types are a native feature of all FP languages like F#, Scala, Haskell and together with product types called algebraic data types. Standard examples of sum types with an empty case would be Optional from F# and Maybe from Haskell. TypeScript doesn't have ADT's, but instead it has a discussion in progress about adding non-nullables that would model one special case of what ADT's would have covered. So my message is, ditch the non-nullables for ADT's.

@spion, Bad news: F# got nulls (as legacy of .NET). Good news: no one uses them. How can you not use null when it's there? They have Optionals (just like the most recent Java as you mentioned). So you don't need null if you have a better choice at your disposal. This is what I am ultimately suggesting: leave nulls (non-nulls) alone, just forget they exist, and implement ADT's as a language feature.

We use null but not the same way you people use. My company source code comes in 2 parts.

1) When it comes to data (like database data), we replace null with blank data at the time of variable declaration.

2) All others, like programmable objects, we use null so we know when there's a bug and loophole in source code where objects aren't created or assignable that aren't necessary javascript objects. The undefined is javascript object issues where there's a bug or loophole in the source code.

The data we don't want to be nullable cuz it is customer data and they'll see null wordings.

@aleksey-bykov typescript has adt with union type, the only thing missing is pattern matching but that's a feature that just cannot be implemented with the typescript philosophy of generating javascript close to the original source.

On the other end it's impossible to define whith union type the exclusion of null value, that's why we need non-null type.

@fdecampredon, TS doesn't have ADT's, it has unions which are not sum types, because, as you said, 1. they cannot model an empty case correctly since there is no unit type, 2. there is no reliable way to destructure them

pattern matching for ADT's can be implemented in a way that is aligned closely with generated JavaScript, anyway I hope that this argument isn't a turning point

@aleksey-bykov this is not F#. Its a language that aims to model the types of JavaScript. JavaScript libraries use null and undefined values. Therefore, those values should be modeled with the appropriate types. Since not even ES6 supports algebraic data types, it doesn't make sense to use that solution given TypeScript's design goals

Additionally, JavaScript programmers typically use if checks (in conjuction with typeof and equality tests), instead of pattern matching. These can already narrow TypeScript union types. From this point its only a tiny step to support non-nullable types with benefits comparable to algebraic Maybe etc.

I'm surprised that nobody actually mentioned the huge changes that lib.d.ts may need to introduce and potential problems of the transient null state of class fields during constructor invocation. Those are some real, actual potential issues to implement non-nullable types...

@Griffork the idea is to avoid having null checks everywhere in your code. Say you have the following function

declare function getName(personId:number):string|null;

The idea is that you check whether the name is null only once, and execute all the rest of the code free from worries that you have to add null checks.

function doSomethingWithPersonsName(personId:number) {
  var name = getName(personId);
  if (name != null) return doThingsWith(name); // type guard narrows string|null to just string
  else { return handleNullCase(); }
}

And now you're great! The type system guarantees that doThingsWith will be called with a name that is not null

function doThingsWith(name:string) {
  // Lets create some funny versions of the name
  return [uppercasedName(name), fullyLowercased(name), funnyCased(name)]
}

None of these functions need to check for a null, and the code will still work without throwing. And, as soon as you try to pass a nullable string to one of these functions, the type system will tell you immediately that you've made an error:

function justUppercased(personId:number) {
  var name = getName(personId);
  return uppercasedName(name); // error, passing nullable to a function that doesn't check for nulls.
}

This is a huge benefit: now the type system tracks whether functions can handle nullable values or not, and furthermore, it tracks whether they actually need to or not. Much cleaner code, less checks, more safety. And this is not just about strings - with a library like runtime-type-checks you could also build type guards for much more complex data

And if you don't like the tracking because you feel that its not worth modeling the possibility of a null value, you can revert back to the good old unsafe behavior:

declare function getName(personId:number):string;

and in those cases, typescript will only warn you if you do something that is obviously wrong

uppercasedName(null);

I frankly don't see downsides, except for backward-compatibility.

@jbondc there is one https://github.com/Microsoft/TypeScript/issues/186

@fdecampredon Union types are just that, unions. They are not _disjoint_ unions a.k.a. sums. See #186.

@aleksey-bykov

Note that adding an option type is still going to be a breaking change.

// lib.d.ts
interface Document {
    getElementById(id: string): Maybe<Element>;
}

...

// Code that worked with 1.3
var myCanvas = <HTMLCanvasElement>document.getElementById("myCanvas");
// ... now throws the error that Maybe<Element> can't be cast to an <HTMLCanvasElement>

After all, you can get a poor man's option types right now with destructuring

class Option<T> {
    hasValue: boolean;
    value: T;
}

var { hasValue, myCanvas: value } = <Option<HTMLCanvasElement>> $("myCanvas");
if (!hasValue) {
    throw new Error("Canvas not found");
}
// Use myCanvas here

but the only value from this is if lib.d.ts (and any other .d.ts, and your whole codebase but we'll assume we can fix that) also use it, otherwise you're back to not knowing whether a function that doesn't use Option can return null or not unless you look at its code.

Note that I also am not in favor of types being non-null by default (not for TS 1.x anyway). It is too big a breaking change.

But let's say we're talking about 2.0. If we're going to have a breaking change anyway (adding option types), why not make types non-nullable by default as well? Making types non-nullable by default and adding option types is not exclusive. The latter can be standalone (eg. in F# as you point out) but the former requires the latter.

@Arnavion, there is some misunderstanding, I didn't say we need to replace the signatures, all existing signatures stay intact, it's for the new developments you are free to go either with ADT or whatever else you want. So no breaking changes. Nothing is being made non-null by default.

If ATDs are here, it's up to a developer to wrap all places where nulls can leak into the application by transforming then into optionals. This can be an idea for a standalone project.

@aleksey-bykov

I didn't say we need to replace the signatures, all existing signatures stay intact

_I_ said that the signatures need to be replaced, and I gave the reason already:

but the only value from this is if lib.d.ts (and any other .d.ts, and your whole codebase but we'll assume we can fix that) also use it, otherwise you're back to not knowing whether a function that doesn't use Option can return null or not unless you look at its code.

Nothing is being made non-null by default. Ever.

For TS 1.x, I agree, only because it is too big a breaking change. For 2.0, using option type in the default signatures (lib.d.ts etc.) would already be a breaking change. Making types non-nullable by default _in addition to that_ becomes worth it and carries no downsides.

I disagree, introducing optionals should not break anything, it's not like we either use optionals or nullables or non-nullables. Everyone uses whatever they want. Old way of doing things should not depend on new features. It's up to a developer to use an appropriate tool for his immediate needs.

So you're saying that if I have a function foo that returns Option<number> and a function bar that returns number, I'm not allowed to be confident that bar cannot return null unless I look at the implementation of bar or maintain documentation "This function never returns null."? Don't you think this punishes functions which will never return null?

function bar from your example was known as nullable from the begging of time, it was used in some 100500 applications all around and everyone treated the result as nullable, now you came around and looked inside of it and discovered that null is impossible, does it mean that you should go ahead and change the signature from nullable to non-nullable? I think you should not. Because this knowledge, although valuable, isn't worth braking 100500 applications. What you should do is to come up with a new lib with revised signatures that does it like this:

old_lib.d.ts

...
declare function bar(): number; // looks like can return a potentially nullable number
...

revised_lib.d.ts

declare function bar(): !number; // now thank to the knowledge we are 100% certain it cannot return null

now the legacy apps keep using the old_lib.d.ts, for new apps a developer is free to choose revised_libs.d.ts

Unfortunately revised_libs.d.ts has 50 other functions that I haven't looked at yet, all of which return number (but I don't know whether it's really number or nullable number). What now?

Well, take your time, ask for help, use versioning (depending on the level of knowledge you've gained so far you may want to release it graduately with ever increasing version number: revised_lib.v-0.1.12.d.ts)

It's not necessary actually. A function that returns nullable type in the signature but non-nullable type in the implementation only results in redundant error checking by the caller. It doesn't compromise safety. Gradually annotating more and more functions with ! as you discover them will work just fine, as you said.

I'm not a fan of ! only because it's more baggage to type (both in terms of keystrokes and needing to remember to use it). If we want non-nullability in 1.x then ! is one of the options already discussed above, but I would still say that having an eventual breaking change with 2.0 and making non-nullability the default is worth it.

On the other hand, maybe it'll lead to a Python 2/3-esque situation, where nobody upgrades to TS 2.0 for years because they can't afford to go through their million-line codebase making sure that every variable declaration and class member and function parameter and... is annotated with ? if it can be null. Even 2to3 (the Python 2 to 3 migration tool) doesn't have to deal with wide-ranging changes like that.

Whether 2.0 can afford to be a breaking change depends on the TS team. I would vote for yes, but then I don't have a million-line codebase that will need fixing for it, so maybe my vote doesn't count.

Perhaps we should ask the Funscript folks how they reconcile DOM API returning nulls with F# (Funscript uses TypeScript's lib.d.ts and other .d.ts for use from F# code). I've never used it, but looking at http://funscript.info/samples/canvas/index.html for example it seems the type provider does not think that document.getElementsByTagName("canvas")[0] can ever be undefined.

Edit: Here it seems document.getElementById() is not expected to return null. At the very least it doesn't seem to be returning Option<Element> seeing it is accessing .onlick on the result.

@spion
Thanks, I hadn't thought of that.

At work our codebase is not small, and this breaking change that people want would set us back a lot of time with very little gain. Through good standards and clear communication between our developers we've not had problems with nulls appearing where they shouldn't.
I am honestly surprised that some people are pushing for it so badly.
Needless to say this would give us very little benefit and would cost us a lot of time.

@Griffork have look at this filtered list of issues in the typescript compiler for an estimate on how big of a benefit this change could make. All of the "crash" bugs listed at that link could be avoided by using non-nullable types. And we're talking about the awesome Microsoft level of standards, communication and code-review here.

Regarding breakage, I think that if you continue using existing type definitions its possible that you wont get any errors at all, except the compiler pointing out potentially uninitialized variables and fields leaking out. On the other hand, you might get a lot of errors, particularly e.g. if class fields are often left uninitialized in constructors in your code (to be initialized later). Therefore I understand your concerns, and I'm not pushing for a backward-incompatible change for TS 1.x. I still hope that I've managed to persuade you that if any change to the language was worthy of breaking backward compatibility, its this one.

In any case, Facebook's Flow does have non-nullable types. Once its more mature, it might be worth investigating as a replacement of TS for those of us who care about this issue.

@spion, the only number your list gives us is how many times null or undefined were mentioned for any reason out there, basically it only says that null and undefined have been talked about, I hope it's clear that you cannot use it as an argument

@aleksey-bykov I am not - I looked at _all_ the issues on that filtered list and every single one that had the word "crash" in it was related to a stack trace which shows that a function attempted to access a property or a method of an undefined or null value.

I tried to narrow the filter with different keywords and I (think I) managed to get all of them

@spion
Question: how many of those errors are caused in locations that they would need to mark the variable as nullable or undefinable though?

E. G. If an object can have a parent, and you initialise parent to null, and you're always going to have one object with a parent that is null, you will still have to declare the parent as possibly null.
The problem here is if a programmer writes some code with the assumption that a loop will always break before it reaches the null parent. That's not a problem with null being in the language, the exact same thing would happen with undefined.

Reasons for keeping null as easy to use as it is now:
• It's a better default value than undefined.
. 1) it's faster to check in some cases (our code must be very performant)
. 2) it makes for in loops work more predictably on objects.
. 3) it makes array usage make more sense when using nulls for blank values (as opposed to missing values). Note that delete array[i] and array[i] = undefined have different behaviour when using indexOf (and probably other popular array methods).

What I feel the result of making nulls require extra mark up to use in the language:
• I got an undefined error instead of a null error (which is what would happen in most of the typescript scenarios).

When I said we don't have a problem with nulls escaping, I meant that variables that are not initialised to null never become null, we still get null exception errors in exactly the same place we would get undefined errors (as does the Typescript team). Making null harder to use (by requiring extra syntax) and leaving undefined the same will actually cause more problems to some developers (e. g. us).

Adding extra syntax to use null means that for several weeks / months developers who use a lot of null will be making errors left, right and center while they try to remember the new syntax. And it will be another way to slip up in the future (by annotating something slightly incorrectly). [Time to point out that I hate the idea of using symbols to represent types, it makes the language less clear]

Until you can explain to me a situation in which null causes an error or problem that undefined would not, then I won't agree with making null significantly harder to use than undefined. It has it's use case, and just because it's not helping you, doesn't mean that the breaking change that you want (that _will_ hurt the workflow of other developers) should go ahead.

Conclusion:
There is no point in being able to declare non-nullable types without being able to define non-undefined types. And non-undefined types are not possible due to the way javascript works.

@Griffork when I say non-nullable, I mean non-nullable-or-undefined. And its not true that its not possible due to the way JS works. With the new type guard features, once you use a type guard you know that the value flowing from there cannot be null or undefined anymore. There is a tradeoff involved there too, and I submit Facebook Flow's implementation as proof that its quite doable.

The _only_ case that will become slightly harder to use is this one: I will temporarily assign null to this variable then I will use it in this other method as if it not null, but I know that I'll never call this other method before initializing the variable first, so there is no need to check for nulls. This is very brittle code, and I would definitely welcome the compiler warning me about it: its a refactor away from being a bug anyway.

@spion
I do believe that I'm finally understanding where you're coming from.

I believe that you're wanting type guards to help determine when a value cannot be null, and allow you to call functions that don't check for null within. And if the guarding if-statement is removed, then that becomes an error.

I can see that being useful.

I also believe that this isn't really going to be the silver bullet you're hoping for.

A compiler that does not run your code and test every facet of it is not going to be better at determining where undefineds/nulls are than the programmer who wrote the code. I am concerned that this change would lull people into a false sense of security, and actually make null/undefined errors more difficult to track when they do occur.
Really, I think the solution that you need is a good set of testing tools that support Typescript, that can reproduce these sort of bugs in Javascript, rather than implementing a type in a compiler that can not deliver on it's promise.

You mention Flow as having a solution to this problem, but when reading your link I saw some concerning things:

"Flow can sometimes also adjust types of object properties, especially when there are no intermediate operations between a check and a use. In general, though, aliasing of objects limits the scope of this form of reasoning, since a check on an object property may be invalidated by a write to that property through an alias, and it is difficult for a static analysis to track aliases precisely."

"Undefined values, just like null, can cause issues too. Unfortunately, undefined values are ubiquitous in JavaScript and it is hard to avoid them without severely affecting the usability of the language[...] Flow makes a tradeoff in this case: it detects undefined local variables and return values, but ignores the possibility of undefined resulting from object property and array element accesses."

Now undefined and null work differently, undefined errors can still show up everywhere, the question mark cannot guarantee that the value is not null, and the language behaves more differently to Javascript (which is what TS is trying to avoid from what I've seen).

p.s.

foo(thing: whatiknowaboutmyobject) {
    if (thing.hidden) {
        delete thing.description;
    }
}

if (typeof thing.description === "string") {
    //thing.description is non-nullable now, right?
    foo(thing);
    //What is thing.description?
    console.log(thing.description.length);
}

TS is already vulnerable to aliasing effects (as is any language that allows mutable values). This will compile without any errors:

function foo(obj: { bar: string|number }) {
    obj.bar = 5;
}

var baz: { bar: string } = { bar: "5" };

foo(baz);

console.log(baz.bar.charAt(0)); // Runtime error - Number doesn't have a charAt method

The Flow docs are stating this only for completeness.

Edit: Better example.

Old:

Yes, but I argue that the means of setting something to undefined is much greater than the means of setting something to another value.

I mean,

mything.mystring = 5; // is clearly wrong.
delete mything.mystring; //is not clearly wrong - this is not quite the equivalent of setting mystring to >undefined.

Edit:
Meh, at this point it's pretty much personal preference. After using javascript for ages, I do not think this suggestion is going to help the language. I think it's going to lull people into a false sense of security, and I think that it will drive Typescript (as a language) away from Javascript.

@Griffork For an example of how the current typescript luls you into a false sense of security, try the example you presented in the playground:

var mything = {mystring: "5"}; 
delete mything.mystring;
console.log(mything.mystring.charAt(1));

By the way, the delete operator could be treated the same way as assigning a value of type null and that would be sufficient to cover your case too.

The claim that the language will behave differently than JavaScript is true, but meaningless. TypeScript already has behavior different than JavaScript. The point of a type system has always been to disallow programs that don't make sense. Modelling non-nullable types simply adds a couple of extra restrictions. Disallowing the assignment of null or undefined values to a variable of non-nullable type is precisely the same as disallowing the assignment of a number to a variable of type string. JS allows both, TS could allow neither

@spion

the idea is to avoid having null checks everywhere in your code

If I understand what you are advocating:

A. Make all types non-null by default.
B. Mark fields and variables that are nullable.
C. Ensure the application/library developer checks all entry points into the application.

But doesn't that mean the onus for ensuring one's code is free of nulls is on the person writing the code, and not on the compiler? We are effectively telling the compiler "dw, I'm not letting any nulls into the system."

The alternative is to say, nulls are everywhere, so don't bother, but if something is non-nullable then I'll let you know.

The fact is the latter approach is prone to null reference exceptions, but it's more truthful. Pretending that a field on an object obtained over the wire (i.e. ajax) is non-null implies having faith in God :smiley: .

I believe there is strong disagreement on this issue because, depending on what one is working on, item C above could either be trivial or infeasible.

@jbondc I'm glad you asked that. Indeed CallExpression is marked as undefined or nullable. However, the type system currently does not take any advantage of that - it still allows all the operations on typeArguments as if it isn't null or undefined.

However, when using the new union types in combination with non-nullable types, the type could be expressed as NodeArray<TypeNode>|null. Then the type system will not allow any operations on that field unless a null check is applied:

if (ce.typeArguments != null) {
  callSomethingOn(ce.typeArguments)
}

// callSomethingOn doesn't need to perform any checks

function callSomethingOn(na:NodeArray<TypeNode>) {
...
}

With the help of TS 1.4 type guards, inside the if block the type of the expression will be narrowed to NodeArray<TypeNode> which in turn will allow all NodeArray operations on that type; additionally, all functions called within that check will be able to specify their argument type to be NodeArray<TypeNode> without performing any more checks, ever.

But if you try to write

function someOtherFunction(ce: CallExpression) {
  callSomethingOn(ce.typeArguments)
}

the compiler will warn you about it at compile time, and the bug simply wouldnt've happened.

So no, @NoelAbrahams, this is not about knowing everything for certain. Its about the compiler helping you tell what value a variable or field can contain, just like with all other types.

Of course, with external values, as always, its up to you to specify what their types are. You can always say that external data contains a string instead of a number, and the compiler wont complain yet your program will crash when trying to do string operations on the number.

But without non-nullable types, you don't even have the ability to say that a value can't be null. The null value is assignable to each and every type and you can't make any restrictions about it. Variables can be left uninitialized and you wont get any warnings since undefined is a valid value for any type. Therefore, the compiler is unable to help you catch null and undefined-related errors at compile time.

I find it surprising that there are so many misconceptions about non-nullable types. They're just types that can't be left uninitialized or can't be assigned the values null or undefined. This isn't that dissimilar to being unable to assign a string to a number. This is my last post on this issue, as I feel that I'm not really getting anywhere. If anyone is interested in finding out more, I recommend starting with the video "The billion dollar mistake" I mentioned above. The issue is well known and tackled by many modern languages and compilers successfully.

@spion, I do entirely agree about all the benefits of being able to state whether a type can or cannot be null. But the question is do you want types to be non-null _by default_?

Pretending that a field on an object obtained over the wire (i.e. ajax) is non-null implies having faith in God

So don't pretend. Mark it as nullable and you'll be forced to test it before using it as non-nullable.

Sure. It boils down to whether we want to mark a field as nullable (in a system where fields are non-null by default) or whether we want to mark a field as non-nullable (in a system where fields are nullable by default).

The argument is that the former is a breaking change (which may or may not be of significance) and also untenable because it requires the application developer to check and guarantee all entry points.

@NoelAbrahams I don't see why it's 'intenable' basically most of the time you don't want null, also when an entry point can return null you will have to check it, in the end a type system with non-null type as default will allows you to make less null check because you will be able to trust some api/library/entry point in your application.

When you think a bit about it marking a type as non null in a nullable type system has limited value, you will still be able to consume nullable typed variable/return type without being forced to test it.
It will also force definition author to write more code, since most of the time well designed library never return null nor undefined value.
Finally even the concept is strange, in a type system with non nullable type, a nullable type is perfectly expressible as an union type: ?string is the equivalent of string | null | undefined. In a type system with nullable type as default where you can mark type as non nullable how would you express !string ? string - null - undefined ?

In the end I don't really understand the concern of people here, null is not a string, in the same way than 5 is not a string, both value won't be able to be used where a string is expected, and letting slip var myString: string = null is as error prone as: var myString: string = 5.
Having null or undefined assignable to any type is perhaps a concept that developer are familiar with, but it is still a bad one.

I don't think I was entirely correct in my previous post: I'll blame it on the hour.

I've just looked through some of our code to see how things would work and it would certainly help to mark certain fields as nullable, for example:

interface Foo {
        name: string;
        address: string|null; /* Nullable */
}

var foo:Foo = new FooClass();
foo.name.toString(); // Okay
foo.address.toString(); // Error: do not use without null check

But what I do object to is the following:

foo.name = undefined; // Error: non-nullable

I feel this will interfere with the natural way of working with JavaScript.

The exact same could apply with number :

interface Foo {
        name: string;
        address: string|number; 
}
var foo:Foo = new FooClass();
foo.name.toString(); // Okay
foo.address.slice() // error

foo.name  = 5 // error

And it's still valid in JavaScript

Reasonably how many time do you willingly assign null to a property of an object ?

I think that most things would be marked as null but you'd be relying on type guards to declare that the field is now non nullable.

@fdecampredon
Quite a lot actually.

@Griffork,

I think that most things would be marked as null

That was my initial thought. But after going through some sections of our code I found comments such as the following:

interface MyType {

     name: string;

     /** The date the entry was updated from Wikipedia or undefined for user-submitted content. */
     wikiDate: Date; /* Nullable */
}

The idea that a field is nullable is often used to provide information. And TypeScript will catch errors if it requires a type guard when accessing wikiDate.

@fdecampredon

foo.name = 5 // error
And it's still valid in JavaScript

True, but that is an error because TypeScript knows with 100% certainty that it was not intentional.

whereas

foo.name = undefined; // Do not send name to server

is perfectly intentional.

I think the implementation that would most closely fit our requirements is to not use union types, but go with the original suggestion:

 wikiDate: ?Date;

I agree with @NoelAbrahams

foo.name = 5 // error
And it's still valid in JavaScript
True, but that is an error because TypeScript knows with 100% certainty that it was not intentional.

The compiler just know that you marked name as string and not string | number if you want a nullable value you would just mark it as ?string or string | null ( which is pretty much equivalent )

I think the implementation that would most closely fit our requirements is to not use union types, but go with the original suggestion:

wikiDate: ?Date;

So we are agree type are non null by default and you would mark nullable with ? :) .
Note that it would be an union type since ?Date would be the equivalent of Date | null | undefined :)

Oh sorry, I was trying to agree to nullable by default and not null with special typing (the symbols are confusing).

@fdecampredon, actually what it means is when a field or variable is marked as nullable then a type guard is required for access:

var wikiDate: ?Date;

wikiDate.toString(); // error
wikiDate && wikiDate.toString(); // okay

This is not a breaking change, because we should still be able to do this:

 var name: string;   // okay
 name.toString();  // if you think that's fine then by all means

Perhaps you believe that we can't have this without introducing null into union types?

Your first example is absolutely right when you do :

wikiDate && wikiDate.toString(); // okay

you use a typeguard and the compiler should not warn anything.

However your second example is not good

var name: string;   // okay
name.toString();  // if you think that's fine then by all means

the compiler should have an error here, a simple algorithm could just error on the first line (unitialized variable not marked as nullable), a more complex one could try to detect assignation before first usage :

var name: string;   // okay
name.toString();  // error because not initialized

var name: string;
if (something) {
  name = "Hello World";
} else {
  name = "Foo bar";
}
name.toString();  // no error since name will always be initialized.

I don't know exactly where to put the barrier but it would sure need some kind of subtile tunning to not get in the way of the developper.

It's a breaking change and cannot be introduced before 2.0, except perhaps with the 'use nonnull' directive proposed by @metaweta

Why not have:

var string1: string; //this works like typescript does currently, doesn't need type-guarding before use, null and undefined can be assigned to it.
string1.length; //works
var string2: !string; //this doesn't work because the string must be assigned to a non-null and non-undefined value, doesn't need type-guarding before use.
var string3: ?string; //this must be type guarded to non-null, non-undefined before use.
var string4: !string|null = null; //This may be null, but should never be undefined (and must be type-guarded before use).
var string5: !string|undefined; //this may never be null, but can be undefined (and must be type-guarded before use).

And have a compiler flag (that only works if -noimplicitany is on) which says -noinferrednulls, which disables the normal syntax for types (like string, and int) and you have to supply a ? or ! with them (null, undefined and any types being exceptions).

In this manner, non-nullables are an opt-in, and you can use the compiler flag to force a project to be explicity nulled.
The compiler flag errors at the assignment of types, not after (like the previous proposal).

Thoughts?

Edit: I wrote this because it forces the idea of using non-null to be explicit in every action. Anyone who reads the code who comes from any other TS project will know exactly what's happening. Also the compiler flag becomes very obvious if it's on (as blah: string is an error, but blah:!string isn't, similar to the way -noimplicitany works).

Edit2:
DefinatelyTyped could then be upgraded to support noninferrednulls, and they won't change the use of the libraries if people choose to not opt-in to the ? and ! feature.

I don't care whether non-null and non-undefined are opt-in, opt-out, with
type modifiers (!?), a directive, or a compiler flag; I'll do whatever it
takes to get them _so long as they are possible to express_, which is not
currently the case.

On Mon, Dec 22, 2014 at 2:35 PM, Griffork [email protected] wrote:

Why not have:

var string1: string; //this works like typescript does currently., doesn't need type-guarding before use, null and undefined can be assigned to it.
string1.length; //worksvar string2: !string; //this doesn't work because the string must be assigned to a non-null and non-undefined value, doesn't need type-guarding before use.var string3: ?string; //this must be type guarded to non-null, non-undefined before use.var string4: !string|null = null; //This may be null, but should never be undefined (and must be type-guarded before use).var string5: !string|undefined; //this may never be null, but can be undefined (and must be type-guarded before use).

And have a compiler flag (that only works if -noimplicitany is on) which
says -noinferrednulls, which disables the normal syntax for types (like
string, and int) and you have to supply a ? or ! with them (null, undefined
and any being exceptions).

In this manner, non-nullables are an opt-in, and you can use the compiler
flag to force a project to be explicity nulled.
The compiler flag errors at the _assignment of types_, not after (like
the previous proposal).

Thoughts?

Reply to this email directly or view it on GitHub
https://github.com/Microsoft/TypeScript/issues/185#issuecomment-67899445
.

Mike Stay - [email protected]
http://www.cs.auckland.ac.nz/~mike
http://reperiendi.wordpress.com

@Griffork that would be an option, but a bad one in my opinion, and I'll explain why :

• It will cause a lot more works in definition files, since now we will have to check and annotate every type to have the right definition.
• We will ends up writing !string (and sometimes ?string) everywhere on the code which would make the code a lot less readable.
• !string in a system where type are nullable is a strange concept the only way you can't really describe it is string minus null minus undefined, on the contrary ?string is pretty simple to describe in a type system where type are null by default string | null | undefined.
• I foresee a lot of headache ( and perf loss ) to find a type-check algorithm where the compiler understand that string | null require a type guard but string doesn't, you basically introduce a concept where some union type should be treated differently than other.
• And finally the worst part we completely loose type inference var myString = "hello" what myString should be string, ?string or !string ? honestly a big headache in perspective here.

If we don't have non null type as default, the best proposal I have seen here is the 'use non-null' directive proposed by @metaweta.
Sure it needs to be specified nicely but at least with just a use non-null string in all our file we can get a simple an predictable behavior.

@fdecampredon

1. It may be a lot more work in definition files, but _you'd have to do that work anyway_ (to ensure the types are correct) and this time the compiler would remind you of what you haven't edited yet (if using -noimplicitnull).
2. I'm open to other suggestions for annotation. I honestly believe that the current type system has it's place, and should not be _replaced_. I don't think a breaking change is worth it. Instead I think we should find a better way of describing what you're after. (I really, really dislike the idea of representing any of this with symbols, they're not intuitive.)
3. What's hard to describe about it? I've seen discussions elsewhere in typescript where this request (for certain types) has been proposed (without a marker). Did a quick search and I couldn't find the issue, I'll hunt more later.
4. 
   If you're referring to what I had written as !string|null, that would work in the current system if null was treated _like_ {} (but was not assignable to it).
   If you're talking about string|null which I didn't have in my list, then I think null should be ignored in this case. Null and undefined only make sense in unions where every non-null and non-undefined is preceeded with a ! and any isn't an any (this could be a compiler warning/error).
5. Good question, and one that only arises if you're using the -noimplicitnull option, I think the safest option would be to assign it to which ever option is the most likely to cause an early error (probably nullable), but I get the feeling there's a better idea that I'm not thinking of. I wonder if someone else has a suggestion on how this should be approached?

Edit: Added to point 2.
Edit: Fixed typo in point 4.

It may be a lot more work in definition files, but you'd have to do that work anyway (to ensure the types are correct) and this time the compiler would remind you of what you haven't edited yet (if using -noimplicitnull).

Yes and no, check the library that you use and see how much actually returns null or undefined.
it's a pretty rare case, we could only find in this issue very few occurrence for the standard lib and for example Promise library never do it.
My point is that in a type system where type are not nullable by default most of the existing definition files are already valid.

I'm open to other suggestions for annotation. I honestly believe that the current type system has it's place, and should not be replaced. I don't think a breaking change is worth it. Instead I think we should find a better way of describing what you're after. (I really, really dislike the idea of representing any of this with symbols, they're not intuitive.)

I don't think there is such a way but I hope I am wrong, because it has an inestimable value in my opinion.
For the breaking change part why are you so against the 'use non-null' directive ?
Developers who wish a nullable type system would not be impacted at all (unless they already strangely add 'use non-null' at the top of their file but honestly that would be a bit ... weird)
And developers who wish a non-null type system could just use the new directive.

What's hard to describe about it? I've seen discussions elsewhere in typescript where this request (for certain types) has been proposed (without a marker). Did a quick search and I couldn't find the issue, I'll hunt more later.
I just find the concept a bit 'weird' and not very clear, I generally use composition as the main tool for programming, not _decomposition_ but why not.

If you're referring to what I had written as !string|null, that would work in the current system if null was treated like {} (but was not assignable to it). If you're talking about string|null which I didn't have in my list, then I think null should be ignored in this case. Null and undefined only make sense in unions where every non-null and non-undefined is preceeded with a ! and any isn't an any (this could be a compiler warning/error).
I'm referring to the fact that when you decompose the 3 types :

• !sting : string - null - undefined
• string: string | null | undefined
• ?string: string | null | undefined

The 2 latest have basically no difference, but the compiler should know that for string it should not force type-guard check and for ?string it should, that info will have to be propagate everywhere, the algorithm will be a lot more complex that it is actually, and I'm pretty sure I could find strange case with type inference.

Good question, and one that only arises if you're using the -noimplicitnull option, I think the safest option would be to assign it to which ever option is the most likely to cause an early error (probably nullable), but I get the feeling there's a better idea that I'm not thinking of. I wonder if someone else has a suggestion on how this should be approached?

Won't do it would basically introduce the same problem than @RyanCavanaugh commented about when I thought about just introducing a flag that would allow to switch from null as default to null as default.
In this case the former proposition was a lot more simpler.

Again why are you against the 'use non-null' directive, more I think about it more it seems to me the ideal solution.

@fdecampredon
Because the "use non-null" as has been currently proposed changes the way the language is _used_ not the way the language is _written_. Meaning that a function from one location when moved to another location may work differently when it's _used_. You will get compile-time errors that are potentially 1-3 files away because something is typed incorrectly.

The difference between:
string
and
?string
Is that the ? and ! symbol is asking for strict type checking for this variable (much like your "use nonnull" directive would be, but on a per-variable basis). Explain it that way and I think you won't have much trouble with people understanding it.

The difference is of course:
File 1:

//...187 lines of code down...
string myfoo(checker: boolean) {
    if(checker){
        return null;
    }
    else {
        return "hello";
    }
}

File 2:

"use nonnull"
//...2,748 lines of code down...
string myfoo(checker: boolean) {
    if(checker){
        return null; //Error!
    }
    else {
        return "hello";
    }
}

Developers now have to keep a mental map of which files are nonnull and which files aren't. I honestly believe that this is a bad idea (even if most of _your_ code is 'use nonnull').

Edit: Also when you start typing a function and you get the little window that tells you what the function definition is, how do you know if string in that definition is nullable or nonnullable?

@Griffork

• again that is already the case with 'use strict'.
• At least the idea is simple. and introduce simple concept in the type system.
• If a developer move a function in an other file seems a pretty edge case for me, and since the error he will be prompted will be about null check he will quickly be able to understand what's happen ...

Again It's not perfect, but I don't see a better alternative.

Just to be clear, your only problems with what I proposed (after counter-arguments) that I can see are:

• We don't know what the behavior for var mystring = "string" would be
• You don't want to have to type symbols everywhere.

And my concerns with the directive are:

• Non-nulls would not be explicit (but can occur in the same project as nullables). edit: fixed wording to make more sense.
• It will be harder of developers to keep track of whether what they're writing is nullable or isn't nullable.
• The function definitions that you see when you invoke a function (edit: the pop-up supplied by Visual Studio when you start typing a function) may or may not be nullable and you wouldn't be able to tell.
• Once a function is wrapped through 2 or 3 layers, you don't know if it's definition is still correct (as you can't use type-inference through files that don't have "use nonnull").

Honestly the implementation of "use strict" is not something that should be aspired to. It was designed for JavaScript (not Typescript), and in JavaScript there are precious few alternatives. We're using Typescript, so we have the option of doing things better.
And I can't see why the directive is better than forcing developers to be explicit about their intentions (after all, that's the reason Typescript was created, wasn't it?).

Edit: Clarified a point.
Edit: Put string in quotes

Honestly your summary of my concern are a bit small, and does not reflect what I wrote, your proposition add over complexity to the type system, makes the type-check algorithm a headache, is pretty hard to specify with all the edge case it would create specially for type inference, and make code ultra-verbose for nothing. Basically not the right tool for the job.

I want all non-nulls to be explicit (since they can occur in the same project as nullables).

I want the fact that string is actually string | null | undefined without forcing you to check that, explicit.

It will be harder of developers to keep track of whether what they're writing is nullable or isn't nullable.

I doubt there will be a single file in a project without 'use non-null' if the project use nonnullity, and scrolling at the top at your file is not so hard (at least when you write file with less than 500 lines of code which is the majority of the case ...)

The function definitions that you see when you invoke a function may or may not be nullable and you wouldn't be able to tell.

Yes you will if it comes from a module that has a directive 'use non-null' thing will be typed accordingly, if you don't just consider everything as nullable ...

Once a function is wrapped through 2 or 3 layers, you don't know if it's definition is still correct (as you can't use type-inference through files that don't have "use nonnull").

I don't understand your point here.

Honestly the implementation of "use strict" is not something that should be aspired to. It was designed for JavaScript (not Typescript), and in JavaScript there are precious few alternatives. We're using Typescript, so we have the option of doing things better.
And I can't see why the directive is better than forcing developers to be explicit about their intentions (after all, that's the reason Typescript was created, wasn't it?).

TypeScript is a superset of javascript, it has his root in JavaScript and the goal is to allows you to write javascript in a safer way, so reusing a concept of JavaScript seems not unreasonable.

And I can't see why the directive is better than forcing developers to be explicit about their intentions

Because you just won't be able to achieve the same result, for all the reasons I cited having non-nullable type in a nullable type system is just a bade idea.

From my point of view there is 3 viable solution here :

• Breaking changes for 2.0 where types become non-nullable
• Compiler flag that switch to non-nullable type by default like I proposed few dozen of comments up, but @RyanCavanaugh had a good point about that. (event if I honestly think that it worth it)
• 'use non-null' directive

The flag would totally be worth it to me, by the way.

function fn(x: string): number;
function fn(x: number|null): string;

function foo() {
    return fn(null);
}

var x = foo(); // x: number or x: string?

If functions are the only concern, an exception could be made in cases where an overload contains an explicit null argument - it would always take precedence over implicit null (in order to be harmonious with --noImplicitNull). This would also be the interpretation that would make sense to the user (i.e. "what I say explicitly should override what is said implicitly"). Though I do wonder if there are other similar problems with the flag that can't be solved this way. And of course this adds some hackish complexity to both the spec and the implementation :|

1. string|null|undefined was explicit in my proposal using the flag, that's why I left it out.
2. Then why have it per file? I'm suggesting my suggestion because it _doesn't break backwards compatibility_ which is important to me, and probably a lot of other devs. And it can be forced to be project-wide.
3. I use a lot of files I don't create; how would I know that that particular file has "use nonnull"? If I have 100 files made by other people, I have to memorize which of those 100 files is nonnull? (or, _every time_ I use a variable/function from another file, I have to open that file and check it?)
4. Let's see if I can make this clearer: example at the end of the post.
5. Where do you stop? Where do you call it bad? One string or keyword at the beginning of a file should not change the way a file behaves. "use strict" was added to javascript because
   
   
   
   1. No large super-set of Javascript (e.g. Typescript) existed at the time that could do what it wanted.
   
   
   2. It was an attempt to speed up the processing of JavaScript (which in my eyes is the only reason it's excusable).
      
      "use strict" was adopted _not because it was the right thing to do_ but because it was the only way that the browsers could cater to the demands of developers. I would hate to see typescript add 1 (then 2, then 3 then 4) other directives that _fundamentally change the way the language works_ as strings that are declared in some arbitrary scope, and affect some other arbitrary scopes. It's really bad language design. I would be happy if "use strict" didn't exist in Typescript, and instead was a compiler flag (and Typescript emitted it into every file/scope that needed it).
   
   
6. Javascript isn't a "non-nullable type system", Typescript isn't a "non-nullable type system". Introducing the ability to declare non-nullable types does not meant that the whole system is "non-nullable". It isn't the point of Typescript.

File 1:
"use notnull"
export string foo() {
    return "mygeneratedstring";
}
File 2:
export string foo() {
    return file1.foo()
}
File 3:
"use notnull"
file2.foo(); //???

You actually have the ability to lose contextual information while still using the same syntax! That's not something I look forward to having in any language I use.

We seem to be arguing in circles. If I am not making sense to you then I am sorry, but you seem to be repeatedly raising the same issues, and I am repeatedly replying to them.

@spion
In that example string isn't an implicit null (I believe it assumes that the --noImplicitNull flag is on)

string|null|undefined was explicit in my proposal using the flag, that's why I left it ou

What I mean is that in the actual system var myString: string is implicitly var myString: (string | null | undefined); and that in top of that the compiler does not force you to use typeguard unless all the other union type.

Then why have it per file? I'm suggesting my suggestion because it doesn't break backwards compatibility which is important to me, and probably a lot of other devs. And it can be forced to be project-wide.
Directive does not break backward compatibility (unless you used a string literal 'use not-null' in a position of a directive for a pretty strange reason, which I bet nobody does), Also at some point TypeScript will have to break backward compatibility, that's why semver defined major version, but that's another story.

I use a lot of files I don't create; how would I know that that particular file has "use nonnull"? If I have 100 files made by other people, I have to memorize which of those 100 files is nonnull? (or, every time I use a variable/function from another file, I have to open that file and check it?)

If you are in a project with guidelines etc etc like every project is organized normally you know ... in the worst case you just have to scroll a bit ... does not seems so hard ...

Where do you stop? Where do you call it bad? One string or keyword at the beginning of a file should not change the way a file behaves. "use strict" was added to javascript because
No large super-set of Javascript (e.g. Typescript) existed at the time that could do what it wanted.
It was an attempt to speed up the processing of JavaScript (which in my eyes is the only reason it's excusable). "use strict" was adopted not because it was the right thing to do but because it was the only way that the browsers could cater to the demands of developers. I would hate to see typescript add 1 (then 2, then 3 then 4) other directives that fundamentally change the way the language works as strings that are declared in some arbitrary scope, and affect some other arbitrary scopes. It's really bad language design. I would be happy if "use strict" didn't exist in Typescript, and instead was a compiler flag (and Typescript emitted it into every file/scope that needed it).

'use strict' was introduced to change the language behavior and maintain retro compatibility, the exact same problem we face now, and will more or less disappear with the es6 modules (and so use not null could disappear with the next major version of typescript).

Javascript isn't a "non-nullable type system", Typescript isn't a "non-nullable type system". Introducing the ability to declare non-nullable types does not meant that the whole system is "non-nullable". It isn't the point of Typescript.

That sentences does not have any sense for me, JavaScript does not have static type system, so like I said the fact that you can assign null to a variable that was before string can be easily compared to the fact that you can assign 5 to a variable that was string before.
The only difference there is that TypeScript, a type checker created for JavaScript, opinionatedly consider null as assignable to everything and not 5.

For your example yes we loose some information between files, it's an acceptable tradeoff for me but I can understand your concern.

We seem to be arguing in circles. If I am not making sense to you then I am sorry, but you seem to be repeatedly raising the same issues, and I am repeatedly replying to them.

Yes I agree, I doubt there will be any consensus on that one, I honestly think that I will just ends up forking the compiler and adding non null type for myself hoping that one day it will ends up in the main compiler, or that flow mature enough to be usable.

@Griffork by the way I think @spion idea does work, the idea is to say that without the flag string being an implicit nullable number | null would always takes prevalence on the first overload, so in both case foo(null) will be string.

@RyanCavanaugh do you think it could work ?

@fdecampredon

1. "use strict" was introduced to optimize javascript. It had to be consumed by browsers, therefore it had to be in-code. And it had to be backwards compatible, so it had to be a non-functional statement.
   Non-nullable types does not have to be consumed by browsers, so it does not have to have an in-code directive.
2. Sorry, I was referring to something I had forgotten to post, here it is:

According to Facebook: "In JavaScript, null implicitly converts to all the primitive types; it is also a valid inhabitant of any object type."
The reasoning for me to want non-nullable to be explicit (in every action that a developer does) is because by using non-nullable the developer is acknolwedging that they are diverging from the way javascript works, and that a type being non-nullable is not guarenteed (as there are many things that can cause this to go wrong).
A property being non-nullable is a property that can never be deleted.

I've been using Typescript for quite a long time. It was hard for me to initially convince my boss to change from Javascript to Typescript, and it was pretty hard for me to convince him to let us upgrade whenever there was a breaking change (even if there isn't it's not easy). When ES:Harmony is supported by browsers, we will probably want to be using it. If a breaking change happens in Typescript between now and when Typescript supports ES:Harmony (particularly one as prevalent as non-null able) I doubt I'd win that argument. Not to mention the amount of time and money it would cost us for me to retrain all of our devs (I am our "Typescript person", it's my job to train our Typescript developers).
Thus, I am really against introducing breaking changes.
I would not mind being able to use non-nullables myself, if there were a way that I could introduce them into future code without breaking old code (this is the reason for my proposal). Ideally eventually all of our code would be converted, but it would cost us significantly less time and money in training people and using 3rd party libraries.

I like the idea of using symbols (as per my suggestion) instead of a per-file directive, because they have the ability to propagate without contextual loss.

@Griffork Ok like I said I understand your concern, I hope you understand mine.
Now I have not the same opinion, technology changes, nothing is stable (the whole drama around angular 2 has proven that), and I do prefer to break things and have better tools than to stick with what I have, I do think that in the long term it makes me win times and money.
Now like we both concluded earlier I doubt we will have a consensus here, I do prefer the directive, you prefer your proposal.
Anyway like I said for my part I'll just try to fork the compiler and add non-null type, since I think it's not a big change in the compiler.
Thanks for the discussion it was interesting

@fdecampredon

Thanks for the discussion it was

Presuming you meant enlightening(interesting works too :D), I also enjoyed the debate :).
Good luck with your fork, and I hope we get a TS person in here to at least dismiss some of our suggestions (so we know what they definitely don't want to implement).

So to elaborate further on my proposed solution to the problem @RyanCavanaugh described, after adding the null type and the --noImplicitNull flag, the typechecker when run without the flag will have a modified behavior:

Whenever a type overload contains |null (like the given example):

function fn(x: string): number;
function fn(x: number|null): string;

the typechecker will take every overload and make new variants with (implicit) null at that argument position, added at the end of the list:

function fn(x: string): number;
function fn(x: number|null): string;
// implicit signature added at the end, caused by the first overload
function fn(x: null): number;

This results with the same interpretation as the strict --noImplicitNull version: when passed a null, the first matching overload is the explicit number|null. Effectively it makes explicit nulls stronger than implicit ones.

(Yes, I know that the number of implicit definitions grows exponentially with the number of arguments that have |null overloads - I'm hoping there is a faster implementation that "allows" nulls at a second pass if no other types match, but I don't think its going to be a problem either way as I expect this situation to be rare)

Formulated like this I think the change will hopefully be fully backward-compatible and opt-in.

Here are some more ideas about the rest of the behavior:

Assigning null or leaving values uninitialized will also be allowed for values of any type when the flag is not passed.

When the flag is turned on, leaving values uninitialized (unassigned) or null would be allowed until the time they're passed to a function or operator that expects them not to be null. Not sure about class members: they would either

• need to be initialized by the end of the constructor, or
• initialization could be tracked by checking whether member methods that fully initialize them were called.

Explicit null unions will behave similarly to all other unions in both modes. They would require a guard to narrow the union type.

I just read _all_ the comments above and that's a lot. It's disappointing that after so many comments and 5 months, we are still debating the same points: syntax and flags...

I think many people have made strong arguments for the value of static null checking by the compiler in large codebases. I will say nothing more (but +1).

So far the main debate has been about the syntax and the compatibility issue with tons of existing TS code and TS library definitions. I can see why introducing a null type and the Flow syntax ?string seems the cleanest and most natural. But this changes the meaning of string and hence is a _huge_ breaking change for _all_ existing code.

The solutions proposed above for this breaking change are to introduce compiler flags (@RyanCavanaugh has made a very good point why this is a terrible idea) or a per-file directive. This seems like a very hackish stop-gap measure. Moreover I would hate reading code in the middle of a diff review or huge file and not being able to immediately know _for sure_ the meaning of the code I'm looking at. 'use strict'; was cited as a precedent. It's not because TS inherited JS past mistakes that we should repeat them.

That's why I think the "not null" annotation (string!, !string, ...) is the only way to go and I will try to introduce a new argument in the discussion: maybe it's not so bad.

Nobody wants to have bangs (!) all over the code. But we probably don't have to. TS infers a lot about typing.

1. Local variables
I don't expect to annotate my local variables with bangs. I don't care if I assign null to a local variable, as long as I use it in a safe way, which TS is perfectly capable of asserting.

var x: string;  // Nullable
x.toString();  // Error: x can be undefined or null
x = "jods";
x.toUpperCase();  // Fine.
notNull(x);  // Fine

Quite often I use an initializer instead of a type.

var x = "jods";  // x: string (nullable)
notNull(x);  // Fine
x = null;  // Fine
notNull(x);  // Error

2. Function return values
Very often I do not specify the return value. Just as TS infers the type, it can infer whether nullable or not.

function() /* : string! */ {
  return "jods";
}

EDIT: bad idea because of inheritance and function variables, see comment by @Griffork below
Event if I give a return type, TS is perfectly able of adding the "not null" annotation for me.

If you want to override the inferred nullability (e.g. because a derived class may return null although your method doesn't), you specify the type explicitely:

function f() : string {  // f is nullable although this implementation never returns null.
  return "abc";
}

3. Function parameters
Just like you have to explicitely specify a type, that's where you _have to_ indicate if you don't accept nulls parameters:

function (x: string!) { return x.toUpperCase(); } // OK
function (x: string) { return x.toUpperCase(); } // Error

To avoid compilation errors in old code bases, we need a new flag "Null dereference is an error", just like we have "No implicit any". _This flag doesn't change the compiler analysis, only what is reported as an error!_
Is that a lot of bangs to add? Hard to say without doing statistics on real, large codebases. Don't forget that optional parameters are commonplace in JS and they are all nullable, so you would need those annotation if 'not null' was the default.
Those bangs are also nice reminders that null is not accepted for callers, consistent with what they know about string today.

4. Class fields
This is similar to 3. If you need to read a field without being able to infer its content, you need to mark it non-nullable at declaration.

class C {  x: string!; }

function(c: C!) // : string! is inferred
{ return c.x; } // OK, but annotations are required

We could imagine a shorthand for initializer, maybe:

class C {
  x! = "jods"; // Note the bang: x is inferred as !string rather than just string.
}

A similar shorthand is probably desirable for nullable properties if you say not-null is the default with an initializer.
Again it's hard to say if most fields in existing code are nullable or not, but this annotation is very much in line with expectations that devs have today.

5. Declarations, .d.ts
The huge benefit is that all existing libraries do work. They accept null and non-null values as inputs and they are assumed to return a possibly null value.
At first you will need to explicitely cast some return values to "not null", but the situation will improve as the definitions are slowly updated to indicate when they never return null. Annotating the parameters is safer but not required to compile successfully.

I think stating the "not-null" state of a value where the compiler can't infer it can be useful (e.g. when manipulating untyped code, or when the dev can make some assertions regarding the global state of the program) and a shorthand might be nice:

var a: { s: string } = something(); // Notice s is nullable.
notNull(a.s); // Error
notNull(<!>a.s);  // OK, this is a shorthand "not-null" cast, because the dev knows about something().

I think the ability to hint the compiler -- in a simple way -- that something is not null is desirable. This is also true for not-null by default, although it's harder to come with a simple, logical syntax.

Sorry, this was a very long post. I tried to demonstrate the idea that even with "null by default", we wouldn't have to annotate all our code: TS can infer the correctness of most code without our help. The two exceptions are fields and parameters. I think this is not excessively noisy and makes for good documentation. A strong point in favor of this approach is that it is backward compatible.

I agree with most of what you said @jods4 but I have some questions and concerns:

2) if the compiler can automatically convert nullable to non nullable on return types, how can you override this (e. g. for inheritance or functions that get replaced)?

3 & 5) If the compiler can convert nullable to non nullable then a function signature in a code file can now behave differently to the same function signature in a d.ts file.

6) How does the bang work/look when using union types?

2) Good catch. I don't think it would work well with inheritance (or 'delegates') indeed.
Where I work our experience with TS is that we almost never explicitely type return values from functions. TS figures them out and I think TS can figure out the null/not null part.

The only cases where we explicitely specify them is when we want to return an interface or a base class, e.g. for extensibility (including inheritance). Nullability seems to fit this description quite well.

Let's change my proposal above: an explicitely typed return value is _not_ inferred not nullable if it is not declared so. This works well for the cases you suggest. It provides a way to override the compiler inferring "not null" on a contract that might be null in child classes.

3 & 5) With the change above, that's not the case anymore, right? Functions signature in code and definitions now behave exactly the same way.

6) Interesting question!
This one is not great indeed, especially if you add generics to the mix. The only way out that I can think of is that all parts must be non-null. You probably need a null type literal anway because of generics, see my last example.

var x: number | string!; // compiler error
var x: number | string; // x can be null
var x: number! | string!; // x cannot be null
function f<T>() : number | T; // f can be null
function f<T>() : number! | T; // f is nullable if T is nullable
function f<T, G>(): T | G; // f is nullable if T or G is nullable
function f<T>(): T | null; // f is nullable even if T is not nullable.
function f<T>(): T!; // Whatever T is, f never returns null.

// Generics constraint option 1
function f<T!>(x: T!, y: T): T!; // T: not nullable type, x: not-null, y: null, f: not-null
function f<T!>(x: T!, y: T): T;  // T: not nullable type, x: not-null, y: null, f: null

// Generics constraint option 2
function f<T!>(x: T, y: T | null): T; // same as option 1.1
function f<T!>(x: T, y: T | null): T | null;  // same as option 1.2

For the sake of discussion, note that if you went for non-null types by default, you would need to invent new syntax as well: how to express that a generic type must not allow nullable values?
And conversly, how would you specify that even if the generic type T contains null, a function never returns T but never null?

Type literals are ok-ish but not very satisfying either: var x: { name: string }!, especially if they were to span more than one line :(

More examples:
Array of not-null numbers number![]
Not null array of numbers: number[]!
Nothing can be null: number![]!
Generics: Array<number!>[]

2, 3 & 5) I agree with the change to the proposal, that seems like it would work.
6)

function f<T>() : number | T; // f can be null
function f<T>() : number! | T; // f is nullable if T is nullable

I assume that here you mean f can return null, not that f can be assigned to null.

For unions, what do you think of the following syntax being another avialable option? (looks a bit silly, but might be more succinct/easier to follow in some cases).

var x = ! & number | string;

To signify that neither are nullable.

For type literals I would say that you can put the bang on the beginning of the literal expression as well as on the end, as var x: !{name: string}, will be easier to work with in my opinion than having it at the end.

@jods4 did you read about my "explicit null has priority over implicit null" proposed fix? That takes care of the varying semantics issue, I think.

@Griffork
Yes of course, "is nullable" was bad wording for "can return null".

Which makes me think that function f() {} is actually a declaration of f, which can be set later on... do we want to express that f will never be set to null? Like function f!() {}? That seems to be going too far in my opinion. I think the typechecker should assume this is always the case. There are other uncommon edge cases that it can't handle anyway.

Regarding the new option I agree that it looks a bit silly and introduces one additional symbol in type declaration: &, with a single purpose... That doesn't look like a good idea to me. And in several languages & AND binds with higher priority than | OR which is not what happens here.

Putting the bang in front of types is a possible alternative, I guess we should try to rewrite all examples to see what might look better. I think this field shortcut I suggested is going to be a problem:

class C {
  name! = "jods";  // Field inferred string, but marked not nullable.
  // Maybe we could do that instead, which works with "!T" convention:
  name : ! = "jods";
  // That kind of make sense with the proposed <!> cast.
}

@spion
Yes I saw it.

First I'm unsure that it really solve the issue at hand. So with your new definition which overload binds to fn(null)? The 'generated' one that returns number? Isn't that inconsistent with the fact that the second overloads also accepts null but returns string? Or is it a compiler error because you can't perform overloads resolution?

Second I'm pretty sure we can come up with lots of other issues. I think changing the global meaning of source code at the flip of a switch just can't work. Not only in .d.ts, but people love to reuse code (library reuse or even copy-pasting). Your suggestion is that the semantic meaning of my source code depends on compiler flag and that seems a very flawed proposition to me.

But if you can prove that code will compile and run correctly in all cases I'm all for it!

@jods4

In both cases the 2nd overload will be used

function fn(x: string): number;
function fn(x: number|null): string; 

because the 2nd explicit null will take precedence over implicit (first one), no matter which flag is used. Therefore the meaning doesn't change based on the flag.

Since the null type doesn't exist right now, they would be introduced together and the change will be fully backward compatible. Old type definitions will continue to work normally.

@spion
So what was the matter with the implicit function fn(x: null): number;? If the 2nd overload always takes precendence, no matter which flag is used this whole "fix" has no effect at all?

Other question: today all lib definitions have "null allowed" behavior. So until they are _all_ updated, I have to use the "implicitly null" flag. Now with this flag on, how can I declare a function that takes a non-null parameter in my project?

// null by default flag turned on because of 3rd party libs.
function (x: string)   // <- how do I declare this not null?
{ return x.toUpperCase(); }

The fix certainly has an effect. It makes the behavior with and without the flag consistent, which fixes the semantic issue mentioned above.

Secondly, you wont have to use a "null by default" flag for 3rd party libs. The most important thing about this feature is that you wont have to do _anything at all_ to get the benefits in the vast majority of cases.

Lets say that there is a library that calculates the word count for a string. Its declaration is

declare function wordCount(s: string): number;

Lets say your code uses this function this way:

function sumWordcounts(s1:string, s2:string) {
  return wordCount(s1) + wordCount(s2);
}

This program passes under both compilers: even if implicit nulls are disabled. The code is totally backward compatible.

Why? Because the compiler as it is today already has the faith that values are not null everywhere where you try to use them (even though they can theoretically be null).

The new compiler would also assume that the values are not null when you try to use them. It has no reason to believe otherwise, since you haven't specified that the value may be null, so that part of the behavior remains the same. The change in behavior only takes effect when assigning null (or leaving variables uninitialized) and then trying to pass those values to a function like the above. They don't require any changes in other parts of the code that use values normally.

Now lets look at the implementation of wordCount

function wordCount(s) {
  if (s == '') return null;
  return s.split(' ').length
}

Oops, this type doesn't tell the whole story. Its possible for that function to return a null value.

The problem is precisely that. Its impossible to tell the whole story in the current compiler, even if we wanted to. Sure, we say that the return value is a number, which implicitly states it can be null: but the compiler never warns about that when we try to access that potentially null value incorrectly. It always happily thinks its a valid number.

After the noImplicitNull change, we will get the exact same result here if we use the same type definitions. The code will compile without complaints. The compiler will still happily think that wordCount always returns a number. The program can still fail if we pass empty strings, just like before (the old compiler wont warn us that the returned number may be null, and neither will the new one as it trusts the type definition). And if we want the same behavior, we can keep it without changing anything in our code. (1)

However now we will _be able_ to do better: we will be able to write an improved type definition for wordCount:

declare function wordCount(s:string):string|null;

and get a compiler warning whenever we try to use wordCount without checking for a null return value.

The best part is that this improvement is completely optional. We can keep all type declarations as they were and get pretty much the exact same behavior as now. The type declarations wont get worse (2) - they can only be improved to be more precise in the cases where we feel that its necessary.

(1): there is already an improvement here even without making the type definition better. with the new type definitions, you wont be able to accidentally pass null to sumWordcounts and get a null pointer exception when the wordCount function tries to .split() that null.

sumWordcounts(null, 'a'); // error after the change

(2): ok, thats a lie. The type declarations will get worse for a small subset of functions: those that take nullable arguments that aren't optional arguments.

Things will still be fine for optional arguments:

declare function f(a: string, b?:string); 

but not for arguments that aren't optional and can be null

declare function f(a: string, b:string); // a can actually be null

I'd argue that those functions are pretty rare, and the fixes needed will be minimal.

@spion

The fix certainly has an effect. It makes the behavior with and without the flag consistent.

In which way, can you give a full example? You also said:

In both cases the 2nd overload will be used

Which, to me, implies that the fix has no effect?

This program passes under both compilers: even if implicit nulls are disabled. The code is totally backward compatible.

Yes it compiles without error in both cases, but not to the same result. sumWordCounts() will be typed as number! in one case and number? in the second. Changing the semantics of code with a switch is highly _not_ desirable. As demonstrated before, this change could then have global effects, e.g. on overloads resolution.

The new compiler would also assume that the values are not null when you try to use them. It has no reason to believe otherwise

No! This is the whole point: I want the compiler to throw error at me when I use a potentially null value. If it "assumes" not null like I do when I code, then this feature is useless!

The change in behavior only takes effect when assigning null (or leaving variables uninitialized) and then trying to pass those values to a function like the above.

Not sure I understand, as "function like the above" actually accepts nulls...

Reading the end of your last comment, I have the impression that we won't get real static null analysis until we turn on the switch, which you can't do until _all_ your library definitions are fixed. :(

Generally speaking it's hard to fully understand all the cases and how everything works with just words. Some practical examples would be very helpful.

Here's an example and how I would like the compiler to behave:

Assume a library with functions yes(): string! that never returns null and no(): string? that may return null.

The .d.ts definition is:

declare function yes(): string;
declare function no(): string;

I want to be able to create large projects in TS that benefit from statically checked nulls and use the existing library definitions. Moreover I want to be able to transition _progressively_ to a situation where all the libraries are updated with correct nullness information.

Using the proposed not null modifier ! above, I am able to do that:

function x(s: string!) {  // inferred : string, could be explicit if we want to
  return s.length === 0 ? null : s;  // no error here as s is declared not null
}

x(no());  // error: x called with a possibly null parameter
y(<!>yes());  // no error because of not null cast. When .d.ts is updated the cast can be dropped.

How would that work with your idea?

This thread is an overly long discussion (130 comments!), which makes very hard to follow the ideas, suggestions and problems mentionned by everyone.

I suggest that we create external gists with our proposals, including suggested syntax, what is accepted by TS, what is an error and so on.

@spion since your idea involves compiler flags, for each piece of code you should document TS behavior with the flag set and unset.

Here's the gist for !T not-null marker:
https://gist.github.com/jods4/cb31547f972f8c6bbc8b

It's mostly the same as in my comment above, with the following differences:

• I noticed that 'not-null' aspect of function parameters can be safely inferred by compiler (thanks to @spion for that insight).
• I included @Griffork comments, notably about inferring return values and I tried !T instead of T!.
• I added a few sections, e.g. about constructor behavior.

Feel free to comment, fork and create alternative proposals (?T).
Let's try to move this forward.

@jods4

In both cases the 2nd overload will be used

Which, to me, implies that the fix has no effect?

1. It implies that overload resolution is changed to make language semantics consistent for both flags.

Yes it compiles without error in both cases, but not to the same result. sumWordCounts() will be typed as number! in one case and number? in the second. Changing the semantics of code with a switch is highly not desirable. As demonstrated before, this change could then have global effects, e.g. on overloads resolution.

1. There is no number! in my proposal. The type will be simply number in both cases. Which means overload resolution continues to work as normal, except with null values, in which case the new behavior for explicit nulls taking precedence over implicit normalizes semantics in a backward-compatible way.

No! This is the whole point: I want the compiler to throw error at me when I use a potentially null value. If it "assumes" not null like I do when I code, then this feature is useless!

1. The point I was trying trying to express is that there is very little backward incompatibility of the feature (in terms of type declarations). If you don't use it, you get the exact same behavior like before. If you want to use it to express the possibility that a value of null type may be returned, well now you can.

Its as if the compiler used the string type for values of type object and string before, allowing all string methods on all objects and never checking them. Now it would have a separate type for Object, and you can start using that type instead to denote that the string methods aren't always available.

Not sure I understand, as "function like the above" actually accepts nulls...

Lets take a look at this function:

function sumWordcounts(s1:string, s2:string) {
  return wordCount(s1) + wordCount(s2);
}

Under the new compiler flag you wouldn't be able to call it with null values e.g. sumWordCounts(null, null); and thats the only difference. The function itself will compile because the definition of wordCounts says it takes a string and returns a number.

Reading the end of your last comment, I have the impression that we won't get real static null analysis until we turn on the switch, which you can't do until all your library definitions are fixed. :(

A vast majority of code simply doesn't really deal with nulls or undefined values, other than checking whether they're null/undefined and throwing an error to prevent the propagation of that value throughout the codebase to a completely unrelated place, making it hard to debug. There are a few functions here and there using optional arguments, which are recognizable and can probably be modeled accordingly with the new switch. Its not that often that functions return null values like my example (which I used it only to make a point about the feature, not as a representative case)

What I'm saying is that the vast majority of type definitions will remain correct, and for the few remaining cases where we need to make the fix, we could choose not to fix them if we deem the null case to be unimportant, or to change the type accordingly, if we care. Which is completely in line with typescript's goal of progressively "turning the dial up" of getting stronger guarantees whenever we need them.

Okay, so the existing type definitions are

declare function yes(): string;
declare function no(): string;

And lets say your code was written before the feature was added aswell:

function x(s: string) {
  return s.length === 0 ? null : s;
}

Under the new compiler, the behavior will be exactly the same as the old one

x(no());  // no error
x(yes());  // no error

Unless you try something that the compiler knows may be null, like the result of x()

x(x(no())) // error, x(something) may be null

You look at no() and you can either decide that the cases where it returns null are rare so you're not going to model that, or you can fix the type definition.

Now lets see what happens with your proposal: every single line of code that even touches an external library breaks. Functions that had perfectly valid type definitons like above also break. You have to update every single argument annotation everywhere and add the ! to get the compiler to stop complaining, or add null checks everywhere.

The bottom line is that the type system in TypeScript is currently wrong. It has a dual interpretation of null values:

When we try to assign null to some variable of type T, or pass null as an argument where a type T is required, it acts as if the type is T|null.

When we try to use a value of type T, it acts as if the type is T and there is no possibility of null.

Your proposal suggests treating all normal types T as T|null always; mine suggests treating them as just T. Both change the semantics. Both make the compiler behave "correctly"

My argument is that the "just T" variant is much less painful than it looks and in-tune with the vast majority of code.

edit: I just realized that your proposal may be to keep treating types without "!" or "?" the same way as before. Thats backward compatible, yes, but a lot of work to get any benefits (as the vast majority of code simply doesn't deal with null values other than checking/throwing.

@spion

1.It implies that overload resolution is changed to make language semantics consistent for both flags.

You are just stating the same fact but it's still unclear to me which case it addresses and in which way.
That's why I asked for a concrete example.

1.There is no number! in my proposal. The type will be simply number in both cases.

That's incorrect, I know the syntax is different but the underlying concepts are the same. When I say number! I am stressing out a non-null number type, which in your proposal would simply be number. And the second case would not be number in your case, but number | null.

A vast majority of code simply doesn't really deal with nulls or undefined values, other than checking whether they're null/undefined and throwing an error to prevent the propagation of that value throughout the codebase to a completely unrelated place, making it hard to debug. There are a few functions here and there using optional arguments, which are recognizable and can probably be modeled accordingly with the new switch. Its not that often that functions return null values like my example (which I used it only to make a point about the feature, not as a representative case)

I think descriptions such as this one make _lots_ of assumptions and shortcuts. That's why I think that to make progress we need to move on to more concrete examples with code, syntax and explanations to how the system works. You say:

A vast majority of code simply doesn't really deal with nulls or undefined values, other than checking whether they're null/undefined and throwing an error

Very arguable.

There are a few functions here and there using optional arguments.

Even more arguable. JS libraries are full of such examples.

, which are recognizable and can probably be modeled accordingly with the new switch

Make a more concrete proposition because this is a huge shortcut. I think I can see where this is headed for actual JS code, but how would you "recognize" an optional argument inside a declare function(x: {}); or inside an interface?

Its not that often that functions return null values like my example.

Again very arguable. Many functions return a null or undefined value: find (when the item is not found), getError (when there is no error) and so on... If you want more examples just look at standard browser APIs, you'll find _plenty_.

What I'm saying is that the vast majority of type definitions will remain correct.

As you can tell from my previous comments, I'm not convinced of that.

and for the few remaining cases where we need to make the fix, we could choose not to fix them if we deem the null case to be unimportant, or to change the type accordingly, if we care. Which is completely in line with typescript's goal of progressively "turning the dial up" of getting stronger guarantees whenever we need them.

At this point this statement doesn't seem trivial to me. Can you give concrete examples of how that works? Especially the _progressively_ part.

Now lets see what happens with your proposal: every single line of code that even touches an external library breaks. Functions that had perfectly valid type definitons like above also break. You have to update every single argument annotation everywhere and add the ! to get the compiler to stop complaining, or add null checks everywhere.

This is almost completely incorrect. Please read the gist I wrote carefully. You'll notice that actually few not-null annotations are required. But there is _one_ breaking change, yes.

Assume you take an existing code base that uses library definitions and try to compile it with my proposal without changing any code:

• You will get a lot of null analysis benefits, even without annotations (pretty much the same way you get that in the Flow compiler).
• A single thing will break: using the return value of a library function that you know doesn't return null.

declare function f(): string; // existing declaration, but f will never return null.
var x = f();
x.toUpperCase();  // error, possibly null reference.

The long-term fix is to update the library definitions to be more accurate: declare function f(): !string;
The short-term fix is to add a not-null cast: var x = <!>f();.
And to help large projects with lots of dependencies upgrade more easily, I suggest adding a compiler flag similar to "no implicit any": "treat possible null references as warning". This means that you can use the new compiler and wait until libraries have updated definition. Note: unlike your proposition this flag doesn't change compiler semantics. It only changes what is reported as an error.

As I said I'm not sure we're making progress in this debate. I suggest you look at my gist and create one with your own ideas, code examples and behavior under both states of your flag. As we are all coders I think it will be clearer. Also there are lots of edge cases to consider. Having done that I have tons of questions to ask for special situations but it's really no use discussing about concepts and ideas without a precise definition.

There are too many discussions about different things going on in this 130+ comments issue.

I suggest we continue _general_ discussion here.

For discussions of concrete proposals that may implement not-null types in TS, I suggest we open new issues, each about a single design proposal. I created #1800 to discuss the !T syntax.

@spion I suggest you create an issue for your design as well.

Many people want not-null types. It's easy in new languages (e.g. Rust) but it's very hard to retro-fit in existing languages (people have been asking for not-null references in .net for a long time -- and I don't think we'll ever get them). Looking at the comments here show that it's a non trivial issue.
Flow has convinced me this can be done for TS, let's try to make it happen!

@jods4 I'm sorry to say so but your proposal has nothing to do with non-null type, it's more related to some sort of control-flow analysis, hardly predictable, and that completely break retrocompatibility (in fact most of the code that is valid 1.4 ts will fail under the rule described in your gist).
I agree with the fact that the discussion is going nowhere, and that 130 comments+ is perhaps too much. But perhaps it's because there is 2 groups of people discussing here :

• those who think that non-null type should be default and want to find a way to make that happens (through a flag or any other mechanism)
• those who don't want non-null type and just try to avoid their introduction, or to push them in a new syntax.

Those 2 groups of peoples have stopped since a long time listening to each other arguments, and in the end what we need is the point of view of the TS team, until then I'll personally stop trying to discuss more about this subject.

@fdecampredon
Regarding the part about my gist, I copy-pasted your arguments in #1800 and if you are genuinely interested we can discuss why it's a bad design there. I don't really understand your point of view but I don't want to start discussing here, that's why I created #1800 in the first place.

Regarding this thread, I agree with you that the discussion is going nowhere...

As you can tell from my previous comments, I'm not convinced of that.

Well I really don't know how to explain it in any other way - I've already explained it a few times. Let me try one more time.

Right now you cant express that

declare function err():string;

returns null. Its impossible, because typescript will always happily let you do err().split(' '). You are unable to say "that may not be valid".

After this change, you would be able to, by changing string to ?string or string|null

But if you don't, _you don't loose anything_ that you had before the change:

You didn't have null checking before the change, and you don't have after (if you don't do anything). I argued that this is mostly backward compatible. Remains to be demonstrated on larger codebases, of course.

The difference is: you couldn't force null checking before the change, but you _can_ after (progressively, first on the definitions that you care most about, then at other places)

@fdecampredon I still discuss the subject because I feel that there are a lot of misconceptions about the issue and about how "hard" and "strict" it will be to take advantage of the feature. I suspect that a lot of the potential issues are severely overblown. We should probably try and implement a basic variant of --noImplicitNull in a fork - I'm not sure I'll be able to find the time in this next period, but if I do I'll give it a try, sounds like a fun project.

@spion, I'm all for nulls being declared with the null keyword, but what is the behaviour between that and undefined in your proposal?

And @fdecampredon my only request was for not having a large breaking change, particularly one in which errors were shown in the wrong place.

I'm guessing @spion in your current example you could pretty much continue coding Typescript the same way we do now, if you assume that a local variable if not assigned to is converted to nullable and function parameters with a ? can also be null. Well, except for that example you had earlier with the nullable early function parameters.

@spion
What I understand from your last comment is massively different from what I understood before...

So : string is "your old string type that will never be checked for nullness, like <any> is never checked for type correctness".

The new syntax : string | null is backward compatible because it didn't exist before and accessing this type without a null check is an error.

That's interesting and it's hard to grasp all the implications. I'll have to think about it for some time.

First question that comes to mind is how do you put constraints on input values (e.g. function parameters):

declare f(x: string): void;
f(null);

Is this ok or an error? If it's ok, how could I make it an error.

_I still think any idea inside this discussion is lost, don't you want to open a new issue with this idea of yours? We could discuss it there._

@jods that would be an error:

declare f(x: string): void; //string must not be null.
declare f(x: string|null): void; //string may be null (not sure about undefined here).
declare f(x?: string): void; //I assume x may be null or undefined.

@jods4 I don't think we need to create multiple issues on the one topic, then things will just get harder to track as you'll have to go to 10 different proposals just to see if anything has happened /subscribe to 10 different ones. And they'd all have to have links to the other proposals in their introductions so that everyone who goes looking for non-nullability doesn't only see & vote for one.

@fdecampredon I know there's a lot of posts and a lot of unresolved things, but that doesn't mean we should stop trying to find a solution that everyone likes. If you don't like the fact that we're still happy to talk about this and explain ourselves then you're more than welcome to unsubscribe from the topic.

@Griffork
But only after you've turned the magic flag on, right?
So with the flag off you have unchecked code, except new nullables types that didn't exist before; then when you turn the flag on, all types are non-nullable and checked?

I think the end result is probably the best solution. _But it is breaking pretty much all the code that exists today._ Imagine that I have 300K lines of code... I have to add a nullable annotation everywhere a type is actually nullable before I could turn on the flag. That's a huge deal.

If I understand correctly, this is nice for new projects (once .d.ts are updated) but very painful for existing code.

@Griffork my problem with this single issue and its long thread of comments is that it is very hard to have a focused discussion on a single proposal. Subscribing to 3 or 4 issues is not a big deal, and you have good context in each one.

@spion's original proposal had no magic flag. It was a core change to how typescript worked.

Yes, but someone who enters into this discussion should read all that came before it. If you think that people shouldn't read all that came before (and therefore potentially propose the same proposals) _then_ we can split it up; but I do not agree. The point of it being in one place is that although we were talking about different details or different possible implementations we were all talking about the same thing.
The same topic, not different topics.
All of the conversation is centralized, and none of it gets buried by not being responded to.

You can't really break down this conversation by implementation detail either, because a lot of proposals will often touch on many different details that are currently under discussion.

Splitting off the proposals from each other means that if someone spots a flaw they have to go to multiple different threads and write that. People aren't learning from each other's mistakes then, and people have the ability (which they will) to seclude themselves to one discussion and repeat the mistakes outlined in other discussions.

The point is: Splitting the conversation up will cause people to have to repeat a lot of posts because of viewers that are too lazy to read everything in all of the other linked posts (assuming that all of the relevant posts link all of the other posts).

Also @jods4 it's only a breaking change when you assign null to something.

Imo a lot less of a breaking change than your proposal, which would have every single definition that shouldn't have null be assignable to it need to be checked/touched before you can use them and get the benefits of non-nullable types.

Here is an example of what the "upgrade" process might be like to @jods4's and @spion's proposals (assuming any necessary flags are turned on):

function a(arg1: string): string;
a("mystr").toLowerCase(); //errors in @jods4's proposal because a may return null.
a("mystr").toLowerCase(); //fine in @spion's proposal.

a(null).toLowerCase(); //fine in @jods4's proposal because a may accept null.
a(null).toLowerCase(); //errors in @spion's proposal since a doesn't accept null.

Ultimately they both are breaking changes. They're both just as painful to debug, with errors occuring at variable use instead of variable declaration. The difference is that one errors when null is assigned to something (@spion), and the other errors when null isn't assigned to something (@jods4). Personally I assign null to things a lot less often than when I don't assign null to things, so @spion's is less of a change for me to work with.

Other things I like:

• Variable's types not changing on me dynamically. If I wanted that I'd use flow:

var s: string;
s.toUpperCase(); // error
var t = (s || "test").toUpperCase(); // ok. Inferred t: string
yes(t);  // ok
t = no();
yes(t);  // error

Personally I'd want an error if I called no(), not an implicit change of type.

• Nullables containing the word null, rather than some symbol, it's easier to read and less to remember. Really ! should be used for "not" not "not-null". I hate having to remember what a symbol does, just as I hate acronyms, I can never remember them and they significantly slow down my work speed.

@jods4 I know that the current conversation is hard for people to catch up on, but splitting it into separate issues isn't going to help, as we're going to have to raise all of these points in all of them eventually because the uninformed will ask the same questions that we did. That's really not going to _help_ the conversation, it will just make it harder to maintain and keep up with.

@Griffork honestly I read all of it, but I doubt many people will. It went into many different and unrelated sub-discussions and I lost track more than once. But let's not make this thread more heavy than it already is and leave it at that.

It's a breaking change every time you have something that is nullable (which implies it gets assigned null at some point, otherwise it would not really be nullable). The error will be reported where null is assigned / passed to a function, but the fix is at declaration. This includes function declarations, variable declarations, field declarations in classes... A lot of stuff has to potentially get reviewed and modified.

@jods4 the unrealated sub-discussions should have been branched off, not the actual core information. But it's too late to go back and change that now.

@spion I think I have a simpler solution to the @RyanCavanaugh problem with the '-nonImplicitNull' flag, the idea is pretty simple we just have to not allow ?type type|null or type|undefined without this flag.

@fdecampredon then you need two versions of every library available and kept up to date.
It would also kill our process where we have one non strict project for trying out code and running tests that depends on the code of a stricter project.

@jods4

declare f(x: string): void;
f(null);

When using the proposed --noImplicitNull flag, yes, that would be an error.

I'm not comfortable opening an official proposal just yet, I want to at lest do a few more thought experiments or maybe try to implement a simpler version of the idea in a fork.

I noticed that the !T proposal will actually break lots of code as well. Not because the semantics of existing types changed but because the new analysis will raise errors in lots of places.

So I closed it. If we break lots of code I prefer the other approach, it seems cleaner.

I am now convinced that there is no way to introduce this feature without breaking lots of existing code. This is still good for all the code yet to be written and possibly old code can continue to compile without the benefits of null checks by the compiler -- which is exactly how it is today.

I wonder what the stance of offical TS team is regarding the breaking aspect of this vs its benefits.

It's very unlikely we would ever take a break as large as "make everything non-nullable by default". If there were some proposal which would _only_ issue new errors in cases which are obviously bugs, that could be on the table, but proposals like that are hard to come by :wink:

If the scope of impact were smaller -- changes in overload resolution when passing null as an argument, for example, where the exact behavior is not necessarily immediately obvious, that could be a different story.

:+1: sane person detected: @RyanCavanaugh

How about no changes to the existing way that things work, but the introduction of a null type for unions, that forces you to guard the variable before using it (or assigning it to a non-null typed variable)? Default behaviour still allows nulls to be assigned to variables typed normally as well as variables typed with null, however a function that may return null if marked up correctly will force a cast.

This way there are no breaking changes, however with good practices you can still have a bunch of bugs picked up by the typing system with both inferred typing and good coding practices.

Then (later perhaps?) you can add a --noImplicitNullCast flag that prevents null from being assigned to variables that do not have null as part of their typing (this more or less works like @spion's suggestion with the flag enabled).

I imagine this would be not too dissimilar to all normal typing and the addition of the --noImplicitAny flag.

@Griffork
The 1st half of the package (add a null type and forbid dereference without guard) is not 100% compatible. You will break more code than you think. Consider this:

With this new capability many lib defs will be updated, including the built-in one. Let's say they change some signatures to explicitely include null as a possible return value. Some examples:

interface Array<T> {
  find(predicate: (T) => bool) : T | null;
  pop() : T | null;
}
interface Storage {
  getItem(key: string) : any | null;
}

There are many such apis: find returns undefined if no array element match the predicate, pop returns undefined if the array is empty, localStorage.getItem or sessionStorage.getItem both return null if the key was not found.

The following code is legitimate and compiled perfectly before. It will now break with an error:

var xs: string[];
if (xs.length > 0) return xs.pop().trim();  // error xs.pop() may be undefined (false positive)

var items : { id: number }[];
var selectedId : number;
// Assume we are sure selectedId is amongst items
var selectedItem = items.find(x => x.id === selectedId);
selectedItem.toString(); // error selectedItem may be undefined (false positive)

Same idea if you fetch something from localStorage that you know is there. There is plenty of code like that around and it now requires a cast (or some new syntax) to compile and tell the compiler: assume this is not null, I know what I'm doing.

That will include a few actual bugs, sure. But it will also include lots of false positives and these are breaking changes. In 100K+ LOC that's not a trivial compiler upgrade.

This probably means that the only approach that would work is: new code written from scratch or migrated old code takes full advantage of null checking; legacy code has no benefit at all. This being driven by a compiler option (--enableNullAnalysis) and with no "transition" or "progressive" migration path.

Well, yes. But you can always freeze the lib.d.ts for a project or grab an old one.
New typing will break old code, that will happen anyway. Almost all new typing when introduced requires that old code gets updated in some way or another to work correctly (e.g. unions, generics).
This change means that those who want to ignore the update or freeze their library/code definitions won't suffer.
Theoretically most code using those functions should be guarded anyway (and typically are in large codebases) - because there's lurking bugs in your code if you don't. Thus this change would more likely catch errors than cause widespread breaking changes.

Edit
@jods4 why did you use unsafe code as an example when that's exactly the kind of code that could cause an error that we're trying to detect by making this change?

Edit 2
If you don't break _some_ (wrong/unsafe) code, then there's no point to making any change to do with this topic ever.

But then again, since this is just a syntax problem, everything would still compile properly, it would just error all over the place.

_New typing will break old code, that will happen anyway._

This is not the case. Except for exceptional circumstances we would not be adding new features that break existing code. Generics and unions weren't added to lib.d.ts in such a way that requires consumers of lib.d.ts to update their codebase in order to use the new version of the compiler. Yes people could choose to use an older version of the library but it's simply not the case that we're going to take language changes that break lots of existing code (as is the case for essentially all major languages). There will be the occasional exception to this (https://github.com/Microsoft/TypeScript/wiki/Breaking-Changes) but they will be few and far between, most often if we believe the code we're breaking could only be a bug.

But you can always freeze the lib.d.ts for a project or grab an old one

Freezing lib.d.ts (and any other .d.ts I may use BTW) has very strong implications. It means I can't get any updates on the libs I use or the new HTML apis. This is not something to take lightly.

Theoretically most code using those functions should be guarded anyway (and typically are in large codebases) - because there's lurking bugs in your code if you don't.

JS has a tradition of returning undefined (or sometimes null) in a lot of cases that would throw an error in other languages. An example of this is that is Array.prototype.pop. In C# popping from an empty stack would throw. So you could say that it always returns a valid value. In Javascript popping an empty array returns undefined. If your typesystem is strict about that you have to take care of it somehow.

I knew you were going to answer that, which is why I wrote examples that are legitimate, working code. In large code bases you'll find lots of examples where an api may returns null in some situations, but you know that it's safe in your specific case (and so you ignore any safety checks).

I was looking at the micro task part of some library just an hour ago. The main part basically comes down to this:

class MicroTasks {
  queue: Array<() => void>;

  flushQueue() {
    while (queue.length > 0) {
      let task = queue.pop();
      task();  // error possible null dereference (not!)
     }
  }
}

There are lots of cases like this.

Regarding your Edit 2: yes, hopefully this change _will_ catch bugs and point out invalid code. I'm convinced it's useful and that's why I would like it to happen somehow. But the TS team will consider the breaking changes in _valid_ code. There are trade-offs that need to be decided here.

@danquirk Fair, then I guess that this feature can never be implemented.
@jods4 I understand what you're saying, but nullables can never be implemented without breaking that code.

Sad, should I finally close that issue ?

Probably.

I think if we steer clear of the nullable and non-nullable argument...

The problem can be addressed (or mitigated) in a non-intrusive way with a set of new features:

• Introduce the null-typeguard symbol ?<type>
  If a type is annotated with this symbol then it is an error to access it directly

``` TypeScript
var foo: ?string;

foo.indexOf('s'); // Error
foo && foo.indexOf('s'); // Okay
```

• Introduce a flag --nouseofunassignedlocalvar

``` TypeScript
var foo: string;

foo.indexOf('s'); // error

foo = 'bar';

foo.indexOf('s'); // okay
```

Interesting historical note: While trying to find a related issue for this I came across an old issue on codeplex that mentions a --cflowu compiler option back in Feb-2013. @RyanCavanaugh, I wonder whatever happened to that flag?

• Introduce the safe navigation operator #16

TypeScript var x = { y: { z: null, q: undefined } }; console.log(x?.y?.z?.foo); // Should print 'null'

In combination, these features would help to trap more errors around the use of null without actually causing everyone a nervous breakdown.

@NoelAbrahams:
Your first proposal is essentially exactly the same as my last one, you're just using a ? instead of |null (read @jods4's post on the problems with updating lib.d.ts and breaking changes).

Your second proposal has a problem previously addressed by @RyanCavanaugh (above):

Flags that change the semantics of a language are a dangerous thing. One problem is that the effects are potentially very non-local:
...[snip]...
The only safe sort of thing to do is to keep the semantics of assignability the same and change what's an error vs what isn't depending on a flag, much like how noImplicitAny works today.

I'm fairly certain a flag not dissimilar was proposed earlier, and then abandoned because of @RyanCavanaugh's comment.

Your third proposal has very little to do with the current topic (it's no longer about typing and compile-time errors, but catching run-time errors). The reason I say this is because the reason this topic was created was to help reduce needing to do undefined or null checks on variables that are known to be "safe" (with an easy way of keeping track of that), not adding new null or undefined checks everywhere.

Could it be possible to implement one of the proposals suggested, and just not update lib.d.ts to use the nullables (and the other libs)? Then the community could maintain/use their own versions with nullables if they want?

Edit:
Specifically, all libs contain the latest information, but don't have their typing updated to require typeguards.

@RyanCavanaugh I'll come back and discuss that if/when I have a patch that demonstrates that its not that big of a change at all (especially if .d.ts files are not updated).

@danquirk type definitions wont have to be updated. They can remain "wrong" and will be mostly backward-compatible.

Anyway, it seems this issue is a lost cause.

By the way, there was a modified compiler by MSR that did this among other things - are there any papers available with their findings? Edit: found it: http://research.microsoft.com/apps/pubs/?id=224900 but unfortunately, I'm not sure its related.

@Griffork, yes, I'm sure almost everything has been discussed in one form or the other - given the length of the discussion. My summary is a practical one about mitigating the problems around null by introducing a number of related features.

not adding new null or undefined checks everywhere

The trapping of unassigned local variables mitigates this and the safe navigation operator is a proposed ES feature, so it will land in TS at some point.

I also think that probablity this gets into TS is low... :(

The only solution that I can think of is to make null safety an opt-in compiler flag. E.g. introduce the new T | null or ?T syntax but don't raise _any_ error unless the project opts-in. So new projects gets the benefits and so do old projects that choose to make their code compatible with the new feature. Large codebases that are too big to be adapted easily just don't get this feature.

That said, even so there are several issues left to make this feature fly...

@NoelAbrahams sorry, my point was not that it was a bad suggestion, just not the answer that was desired from the instigation of this discussion.
I will certainty be using that feature when(/if) it becomes native, it sounds really good.

@jods4 that has the same problem with the @RyanCavanaugh comment I quoted above (assignments error due to a problem elsewhere when a flag is changed).

Again, easiest way is to implement one of the other proposals (probably @spion's) and not add the new types to the .d.ts'.

@Griffork
Not necessarily, although this is one of the "several issues" left. The feature should be designed so that enabling the flag does _not_ change any program semantics. It should only raise errors.

For example if we go with 'not null' !T design, I don't think we have this issue. But this is far from a solve issue.

I should also point out that while T | null is a breaking change ?T is not.

@jods4 I was under the impression that "changing semantics" included "changing assign-ability", either way my (and possibly @RyanCavanaugh's) concerns about non-local effects still stand.

@NoelAbrahams how?
T | null requires a typeguard, ?T requires a typeguard, they are the same thing with different names/symbols.
Yes, you can have both of them "turned on" with a flag.
I fail to see the difference?

@Griffork, the way I see it ?T simply means "do not access without checking for null". One is free to add this annotation to new code in order to enforce the check. I'm thinking of this as a sort of operator rather than type annotation.

The annotation T|null breaks existing code because it makes a statement about whether types are nullable or not by default.

@jbondc
Interesting... I have not looked too deeply into your proposal yet but I think I will.

At the moment compiler-enforced immutability is not as interesting in JS as in other languages because its threading model prohibits shared data. But surely something to keep in mind.

@NoelAbrahams
All null-enforcing proposals are breaking changes. Even ?T that you described. I showed several examples why a few comments above.

That's why I think the only way out if we want this is to make it a compiler option, and to think this well enough so that enabling the option changes the reported errors but not program behavior. Not sure if it's doable or not.

I'm actually kind-of okay with this. With TS 1.5 I'll be sort-of able to get what I want:

function isVoid(item:any): item is void { return item == null; }
declare externalUnsafeFunction(...):string|void

function test() {
  var res = externalUnsafeFunction(...);
  var words = res.split(' '); // error
  if (!isVoid(res)) {
    var words = res.split(' '); // ok
  }
}

now the isVoid check is forced on return values for externalUnsafeFunction or any other function or function definition where I add |void to the return type.

I still wont be able to declare functions that dont accept null/undefined, but its possible to be diligent enough to remember to initialize local variables and class members.

Because @NoelAbrahams we already discussed that even with a null type, null would still have to be allowed to implicitly cast to any other type unless a future compiler flag changed that.

Also it means that in the future we can bring in a compiler flag that let's us annotate where and when a function can accept null.

And personally I hate the idea of using symbols to represent types when we can use words instead.

@spion that's a good point actually. If that works in TS currently then arguably all built in d.ts files are already "wrong", adding the null type as proposed by you with my suggested modifications won't change anything.

Actually since it's somewhat achievable already I'm going to propose we start using that this week to my boss.

I will caution that we in no way see T|void as a syntax that we would be afraid of breaking in the future. It is nearly nonsense.

@RyanCavanaugh It's about as nonsense as void === undefined (an assignable value).

Sigh.

Our code is too large to start depending on T|void if it will soon break and not be replaced. And I won't be able to convince the other programmers to use it if any week it could break.

Ok, @spion if you ever do make your patch, let me know and I'll run it against my work's codebase. I can at least give statistics about how many errors it causes.

@RyanCavanaugh nonsense, really? In what way? And what would you suggest to express nullable types that are should be forbidden for any kind of consumption before a null/undefined check?

I really have a lot of libraries that would benefit from that.

@Griffork it wont be possible to safely remove void from the union before 1.5 anyway, not without user-defined type guards, so using this will only be possible post 1.5 (if it becomes possible at all)

Nonsense as in would you ever write this code?

var foo: void;
var bar: void = doStuff();

Of course not. So then what is the meaning of adding void to a union of possible types? Note this part of the language spec that has existed for quite awhile in the section describing The Void Type (3.2.4):

_NOTE: We might consider disallowing declaring variables of type Void as they serve no useful purpose. However, because Void is permitted as a type argument to a generic type or function it is not feasible to disallow Void properties or parameters._

This question:

_And what would you suggest to express nullable types that are should be forbidden for any kind of consumption before a null/undefined check?_

is what the entire thread is about. Ryan is merely pointing out that string|void is nonsense according to the current language semantics and so it's not necessarily reasonable to take a dependency on nonsense semantics.

The code I wrote above is afaik perfectly valid TS 1.5, right?

I'll give an example that is certainly not nonsense. We have a (nodejs) database library function we call get() similar to Linq's Single() that unfortunately returns Promise<null> instead throwing an error (a rejected promise) when the item is not found. Its used throughout our codebase in thousands of places and isn't likely to be replaced or go away soon. I want to write a type definition that forces me and the other developers to use a type guard before consuming the value, because we've had dozens of hard to trace bugs stemming from a null value moving far into the codebase before being consumed incorrectly.

interface Legacy { 
  get<T>(...):Promise<T|void>
}

function isVoid(val: any): val is void { return val == null; } // also captures undefined

legacy.get(...).then(val => {
  // val.consumeNormally() is a type error here
  if (!isVoid(val)) { 
    val.consumeNormally(); // OK
  }
  else { handle null case }
});

This looks completely reasonable to me. Adding void to the union causes all operations on val to be invalid, as they should be. The typeguard narrows the type by removing the |void and leaves the T part.

Perhaps the spec doesn't take the implications of unions with void into account?

Dont disallow void variables! They work as unit type values and can be used
in expressions (unlike void in C# which requires 2 sets of everything: one
for actions and one functions). Please leave void alone, ok?
On Jan 27, 2015 8:54 PM, "Gorgi Kosev" [email protected] wrote:

The code I wrote above is afaik perfectly valid TS 1.5, right?

I'll give you an example that is certainly not nonsense. We have a
database library function similar to Linq's Single() that unfortunately
returns Promise instead throwing an error (a rejected promise) when
the item is not found. Its used throughout our codebase in thousands of
places and isn't likely to be replaced or go away soon. I want to write a
type definition that forces me and the other developers to use a type guard
before consuming the value, because we've had dozens of hard to trace bugs
stemming from a null value moving far into the codebase before being
consumed incorrectly.

interface Legacy {
get(...):Promise
}
function isVoid(val: any): val is void { return val == null; } // also captures undefined

legacy.get(...).then(val => {
// val.consumeNormally() is an error
if (!isVoid(val)) {
val.consumeNormally(); // OK
}
else { handle null case }
});

This looks completely reasonable to me. Can you point out which part is
nonsense?

Reply to this email directly or view it on GitHub
https://github.com/Microsoft/TypeScript/issues/185#issuecomment-71767358
.

What I'm saying is that T|void is essentially meaningless right now because we already have the rule that the union of a type and its subtype is equivalent to simply the supertype, e.g. Cat|Animal is equivalent to Animal. Treating void as a stand-in for the values null/undefined isn't coherent because null and undefined are _already in the domain of T_ for all T, which implies they should be subtypes of T

In other words, T|null|undefined, if you could write that, would already be subject to collapsing into T. Treating void as an incantation for null|undefined is wrong because if that actually were the case, the compiler would have collapsed T|void into T already.

I would personally read this http://www.typescriptlang.org/Content/TypeScript%20Language%20Specification.pdf

The only possible values for the Void type are null and undefined. The Void type is a subtype of the Any type and a supertype of the Null and Undefined types, but otherwise Void is unrelated to all other types.

As; in T|void, T is specifically _not_ a supertype of void because the only supertype (according to spec) is any.

Edit: disallowing it is a different issue.

Edit2: Re-read what you said, and it makes sense literally (in the way that the documentation has worded void), but it doesn't make sense in what is assumed to be the common (or correct) interpretation of the documentation.

@RyanCavanaugh I'll use the feature anyway until it breaks, as in the meantime its likely to help me find a lot of bugs.

And I can't help but point out the irony of saying that collapsing T|null|undefined into T "makes sense" while the existence of T|void doesn't. (I know, its about the spec, but still...)

@jbondc

There are no static structural types in ECMAScript, so that argument is invalid. In ECMAScript, all values are of type any therefore anything can be assigned to anything or passed to anything. That fact should not imply anything about TypeScript's static type system, which is there to improve upon the non-existent one in JS

Its a bit sad that I have to explain the irony, but here goes:

1. you have a value that supports no methods and no properties, null
2. you make a type system where this value assignable to variables of any type, most of them supporting various methods and properties (e.g. strings numbers or complex objects var s:string = null)
3. you make a void type that correctly accepts that value and allows no methods or properties, and as a consequence T|void allows no methods and properties.

The claim is that (3) is nonsense, while (2) isn't. Do you see the part that is ironic here? If not, I'll try another example:

1. you have values that support only some methods and properties {}
2. you make a type system where this value is assignable to variables of any type (e.g. to strings numbers or complex objects var s:string = {}) that have a much larger set of methods and properties
3. you have an {} type that correctly accepts {} values and allows no methods or properties other than a few built in ones, and T|{} naturally allows no methods or properties other than the built-in ones of {}

Now which one is nonsense, (2) or (3) ?

What is the only difference between the two examples? A few built in methods.

Finally, the interface was just a type definition description. Its not an interface that is being implemented anywhere. Its the interface provided by the library, which never returns anything other than promises, but may return a promise for null. Therefore the safety is definitely very real.

@spion that's exactly what I was thinking.

Here, I think this will clear things up a little:
According to the Spec:

What is void?

The Void type, referenced by the void keyword, represents the absence of a value and is used as the return type of functions with no return value.

So, void is not null|undefined.

The only possible values for the Void type are null and undefined

So, null and undefined are assignable to void (as they are assignable to pretty much anything else).

Null is a type.

3.2.5 The Null Type
The Null type corresponds to the similarly named JavaScript primitive type and is the type of the null
literal.
The null literal references the one and only value of the Null type. It is not possible to directly reference the Null type itself.

Undefined is a type.

3.2.6 The Undefined Type
The Undefined type corresponds to the similarly named JavaScript primitive type and is the type of the undefined literal.

Void is only a Supertype of the Null and Undefined _types_

. The Void type is a subtype of the Any type and a supertype of the Null and Undefined types, but otherwise Void is unrelated to all other types.

So @jbondc according to the Typescript Language Specification, null is a value, Null is a type, undefined is a value, Undefined is a type, and Void (lower-case when in code) is a type that is a Supertype of Null and Undefined but _does not implicitly cast_ to any other type (except any). In fact, Void is specifically written to have different behaviour to the Null and Undefined types:

Void:

The Void type is a subtype of the Any type and a supertype of the Null and Undefined types, but otherwise Void is unrelated to all other types.

Null:

The Null type is a subtype of all types, except the Undefined type. This means that null is considered a valid value for all primitive types, object types, union types, and type parameters, including even the Number and Boolean primitive types.

Undefined:

The undefined type is a subtype of all types. This means that undefined is considered a valid value for all primitive types, object types, union types, and type parameters.

Clearer now?

What we're asking for is a type that forces a guard for nulls, and a type that forces a guard for undefineds. I'm not asking for null or undefined to not be assignable to other types (that's too breaking), just the ability to opt-in to extra mark-up. Heck, they don't even have to be called Null or Undefined (the types).

@jbondc this is the irony: No matter what the TS compiler says, the null and undefined values in JS will never support any methods or properties (other than throwing exceptions). Therefore, to make them assignable to any type is nonsense, about as much nonsense as allowing the value {} to be assigned to strings. The void type in TS contains no values, _but_ null or undefined are assignable to everyone, and therefore can be assigned to variables of type void, so there is another bit of nonsense right there. And thats the irony - that (via type guards and unions) both currently combine into something that actually makes sense :)

Something as complex as the TS compiler was written without guards, that's something to think about.

There is pretty big application written in PHP or JAVA, that does not make the language better or worse.
Egyptian Pyramides have been built without any modern machine, does that mean that everything we have invented in the past 4500 past year is crap ?

@jbondc See my comment above with the list of issues in the TypeScript compiler caused by null and undefined values (minus the first one on the list)

@jbondc it's not supposed to solve the world's problems, it's supposed to be another tool available at developer's disposal.
It would have the same impact and utility as function overloads, unions and type aliases.
It is another opt - in syntax that allows developers to more accurately type values.

One of the big issues mentioned for making types non-nullable is what to do about existing TypeScript code. There are two issues here: 1) Making existing code work with a newer compiler that supports non-nullable types and 2) Interoperating with code that hasn't been updated - avoiding a Python 2/3 style quagmire

It should be possible though to provide a tool which performs an automated rewrite of existing TS code to make it build and for this limited case, something that works a lot better than say 2to3 did for Python.

Perhaps a gradual migration could look something like this:

1. Introduce support for '?T' syntax to indicate a possibly null type. Initially this has no effect on type checking, it is just there for documentation.
2. Provide a tool which auto-rewrites existing code to use '?T'. The dumbest implementation would convert all uses of 'T' to '?T'. A smarter implementation would check whether the code that used the type implicitly assumed it was non-null and use 'T' in that case. For code which tries to assign a value of type '?T' to a parameter or property expecting 'T', this could wrap the value in a placeholder which asserts (at compile time) that the value is non-null - eg let foo: T = expect(possiblyNullFoo) or let foo:T = possiblyNullFoo!
3. Apply the tool to all the provided type definitions and those in the DefinitelyTyped repository
4. Introduce a compiler warning when trying to assign '?T' to a slot expecting a 'T'.
5. Let the warnings bake in the wild and verify that porting is managable and see how the change is received
6. Make assigning '?T' to a slot expecting a 'T' an error, in a major new release of the compiler.

Perhaps it might also be worth introducing something that would disable the warnings for specific modules to ease use of code which the tool has not yet been applied to.

In the previous comment, I'm assuming that there would be no mode to choose nullability of plain 'T' to avoid splitting the language and that steps 1-3 would be useful on their own even if step 6 never proves practical.

My random thoughts:

1. The expect() part may be complicated, it would need to be well-thought. There are not only assignments, but interfaces, generics or parameter types...
2. I _think_ TS does not have any warning, only errors. If I'm right, I'm not sure they will introduce warnings just for that feature.
3. Even if many people upgrade their code, enterprises may be very slow to do so, or may even never want to do so in the case of large existing codebases. This makes that major release a huge breaking change, something that the TS team doesn't want.

That said, I'm still thinking that an "opt-in" flag to report null errors is an acceptable solution. The issue is that the same code/definitions should have the same behavior (minus the errors) when the flag is off, something I haven't had the time to think through yet.

@jods4 - For the expect() part, my thinking is that wherever you have ?T the compiler sees T | undefined so you could re-use the rules for handling union types as far as possible.

I agree I'm not sure how realistic a 'flag day' is for TypeScript. Aside from an 'opt-in' flag, it could also be an opt-in flag that eventually becomes an opt-out flag. The important thing is to have clear direction about what the idiomatic style is.

Something else relevant to this discussion - https://github.com/rwaldron/tc39-notes/blob/master/es6/2015-01/JSExperimentalDirections.pdf discusses investigations by the Chrome team into using type info (specified via TypeScript-style annotations) in the compiler to optimize JS. There is an open question in there about nullability - they would like non-nullable types but aren't sure about feasibility either.

Just gonna chime back in here. I'm surprised we haven't really resolved this one.

I say there is a value add here. One that is only applicable at compile time.
Instead of having to write more code to null check a value, being able to declare a value as not nullable can save time and coding. If I describe a type as 'non-nullable' then it has to be initialized and possibly asserted as non-null before being passed on to another function that expects non-null.

As I said above, maybe this could simply be solved by a code contracts implementation.

Why can't you just quit using the null literal and guard all places where
nulls can leak into your code? This way you will be safe from null
reference exception without having to do checks for null everywhere.
On Feb 20, 2015 1:41 PM, "electricessence" [email protected] wrote:

Just gonna chime back in here. I'm surprised we haven't really resolved
this one.

I say there is a value add here. One that is only applicable at compile
time.
Instead of having to write more code to null check a value, being able to
declare a value as not nullable can save time and coding. If I describe a
type as 'non-nullable' then it has to be initialized and possibly asserted
as non-null before being passed on to another function that expects
non-null.

As I said above, maybe this could simply be solved by a code contracts
implementation.

Reply to this email directly or view it on GitHub
https://github.com/Microsoft/TypeScript/issues/185#issuecomment-75295204
.

Null checks are significantly faster than undefined checks.
On 21/02/2015 11:54 AM, "Aleksey Bykov" [email protected] wrote:

Why can't you just quit using the null literal and guard all places where
nulls can leak into your code? This way you will be safe from null
reference exception without having to do checks for null everywhere.
On Feb 20, 2015 1:41 PM, "electricessence" [email protected]
wrote:

Just gonna chime back in here. I'm surprised we haven't really resolved
this one.

I say there is a value add here. One that is only applicable at compile
time.
Instead of having to write more code to null check a value, being able to
declare a value as not nullable can save time and coding. If I describe a
type as 'non-nullable' then it has to be initialized and possibly
asserted
as non-null before being passed on to another function that expects
non-null.

As I said above, maybe this could simply be solved by a code contracts
implementation.

Reply to this email directly or view it on GitHub
<
https://github.com/Microsoft/TypeScript/issues/185#issuecomment-75295204>
.

—
Reply to this email directly or view it on GitHub
https://github.com/Microsoft/TypeScript/issues/185#issuecomment-75346198
.

My point that those checks are unnecessary (if the null keyword is banned
and all other places where it can come in are guarded).

Why? 1. The code without checks at all runs significantly faster than code
with checks for nulls. 2. It contains less if's and therefore more readable
and maintainable.
On Feb 20, 2015 7:57 PM, "Griffork" [email protected] wrote:

Null checks are significantly faster than undefined checks.
On 21/02/2015 11:54 AM, "Aleksey Bykov" [email protected] wrote:

Why can't you just quit using the null literal and guard all places where
nulls can leak into your code? This way you will be safe from null
reference exception without having to do checks for null everywhere.
On Feb 20, 2015 1:41 PM, "electricessence" [email protected]
wrote:

Just gonna chime back in here. I'm surprised we haven't really resolved
this one.

I say there is a value add here. One that is only applicable at compile
time.
Instead of having to write more code to null check a value, being able
to
declare a value as not nullable can save time and coding. If I
describe a
type as 'non-nullable' then it has to be initialized and possibly
asserted
as non-null before being passed on to another function that expects
non-null.

As I said above, maybe this could simply be solved by a code contracts
implementation.

Reply to this email directly or view it on GitHub
<
https://github.com/Microsoft/TypeScript/issues/185#issuecomment-75295204

.

Reply to this email directly or view it on GitHub
<
https://github.com/Microsoft/TypeScript/issues/185#issuecomment-75346198>
.

Reply to this email directly or view it on GitHub
https://github.com/Microsoft/TypeScript/issues/185#issuecomment-75346390
.

You're missing the point, we use nulls to avoid undefined checks.
And since our application does not have one consistent state, we do, and
often have to have things be null / undefined instead of an object to
represent that.
On 21/02/2015 12:20 PM, "Aleksey Bykov" [email protected] wrote:

My point that those checks are unnecessary (if the null keyword is banned
and all other places where it can come in are guarded).

Why? 1. The code without checks at all runs significantly faster than code
with checks for nulls. 2. It contains less if's and therefore more readable
and maintainable.
On Feb 20, 2015 7:57 PM, "Griffork" [email protected] wrote:

Null checks are significantly faster than undefined checks.
On 21/02/2015 11:54 AM, "Aleksey Bykov" [email protected]
wrote:

Why can't you just quit using the null literal and guard all places
where
nulls can leak into your code? This way you will be safe from null
reference exception without having to do checks for null everywhere.
On Feb 20, 2015 1:41 PM, "electricessence" [email protected]
wrote:

Just gonna chime back in here. I'm surprised we haven't really
resolved
this one.

I say there is a value add here. One that is only applicable at
compile
time.
Instead of having to write more code to null check a value, being
able
to
declare a value as not nullable can save time and coding. If I
describe a
type as 'non-nullable' then it has to be initialized and possibly
asserted
as non-null before being passed on to another function that expects
non-null.

As I said above, maybe this could simply be solved by a code
contracts
implementation.

Reply to this email directly or view it on GitHub
<

https://github.com/Microsoft/TypeScript/issues/185#issuecomment-75295204

.

Reply to this email directly or view it on GitHub
<
https://github.com/Microsoft/TypeScript/issues/185#issuecomment-75346198

.

Reply to this email directly or view it on GitHub
<
https://github.com/Microsoft/TypeScript/issues/185#issuecomment-75346390>
.

—
Reply to this email directly or view it on GitHub
https://github.com/Microsoft/TypeScript/issues/185#issuecomment-75347832
.

You are missing my points too. In order to keep your state consistent and be able to represent missing values you don't need to use nulls or undefined. There are other ways, especially now with union types support consider:

class Nothing { public 'i am nothing': Nothing; }
class Something { 
    constructor(
    public name: string,
    public value: number
   ) { }
}
var nothing = new Nothing();
var whoami = Math.random() > 0.5 ? new Something('meh', 66) : nothing;

if (whoami instanceof Nothing) {
    console.log('i am a null killer');
} else if (whoami instanceof Something) {
    console.log(whoami.name + ': ' + whoami.value);
}

So we just encoded a missing value without using a null or undefined. Also note that we are doing it in 100% explicit manner. Thank to type guards, there is no way one can miss a check prior to reading a value.

How cool is that?

Do you think that an instance of check is faster than a null check, for an
application that has to do hundreds of these per second?
Let me put it this way: we've had to create aliases for functions because
it's faster to not use '.' accessors.
On 21/02/2015 12:58 PM, "Aleksey Bykov" [email protected] wrote:

You are missing my points too. In order to keep your state consistent and
be able to represent missing values you don't need to use nulls or
undefined. There are other ways, especially now with union types support
consider:

class Nothing { public 'i am nothing': Nothing; }
class Something {
constructor(
public name: string,
public value: number
) { }
}
var nothing = new Nothing();
var whoami = Math.random() > 0.5 ? new Something('meh', 66) : nothing;

if (whoami instanceof Nothing) {
// whoami is nothing
console.log('i am a null killer');
} else if (whoami instanceof Something) {
// whoami is an instance of Something
console.log(whoami.name + ': ' + whoami.value);
}

So just got encoded a missing value without using a null or undefined.
Also note that we are doing it in _100% explicit manner_. Thank to type
guards, there is no way one can miss a check prior to reading a value.

How cool is that?

—
Reply to this email directly or view it on GitHub
https://github.com/Microsoft/TypeScript/issues/185#issuecomment-75349967
.

@aleksey-bykov Note that I addressed that point already: the need to model type definitions for existing libraries that already use null values isn't solved. In that case, you can't just "quit using" null values.

Also, that doesn't even touch upon issues with uninitialized variables that will be undefined. In Haskell, the problem doesn't even exist because you can't leave a value "uninitialized".

@Griffork, I don't think, I run tests, tests say it depends on the browser.
http://jsperf.com/nullable-vs-null-vs-undefined-vs-instanceof
What I think though is that you need to find a balance between the safety and performance. Then you need to measure your performance carefully before trying to optimize it. Chances are you are fixing something that is not broken and your null checks that you so concerned about might constitute less than 2% of the overall performance, if so if you make it double faster you will only gain 1%.

@spion, all things considered it is a much nicer way than keep using nulls in your code, given the current situation and problems non-nullables bring with them

Our code base is over 800 TypeScript files and over 120000 lines of code
and we never needed nulls or undefined when it came to modeling business
domain entities. And although we had to use nulls for DOM manipulations,
all such places are carefully isolated, so that nulls have no way to leak
in. I don't buy your argument that nulls might be needed, there are
production ready languages without nulls at all (Haskell) or with null
banned (F#).
On Feb 22, 2015 9:31 AM, "Jon" [email protected] wrote:

@aleksey-bykov https://github.com/aleksey-bykov From a practical
perspective, you can't ignore null. Here's some background on why you'd
need a nullable type anyway:
https://www.google.com/patents/US7627594?ei=P4XoVPCaEIzjsATm4YGoBQ&ved=0CFsQ6AEwCTge

Reply to this email directly or view it on GitHub
https://github.com/Microsoft/TypeScript/issues/185#issuecomment-75437927
.

Yep, and the most important thing you can understand here is that we're NOT modelling business domain entities, we ARE HIGHLY time sensitive, and our codebase is not too much smaller than yours.

For your purpose you don't need nulls, which is fine, you can go and continue using Typescript without them.
For our purpose we need nulls, and we can't afford not to.

Oh, just saw your other comment, sorry.
If you read a little earlier in this thread, you'll notice that I've said (essentially) that we've always used nulls, and we've rarely had any problems with them seeping into other bits of code.

If you also read above, the non nullable proposal also covers undefined.

Null and undefined in variables for their speed look similar, but as soon as they're present on an object (particularly one with a prototype chain) the story is very different, so we use nulls instead.

Again, probably not worth worrying about, unless (like us), you're doing 10,000 checks in <10ms.

(And yes, we actually changed due to tracking the performance of our application and finding a bottleneck)

I would like to spur some discussion about this. Just yesterday in Build video I saw analyzers implemented in C#. I opened an issue #3003 to implement similar to TypeScript.

Basically analyzer is a library that can do additional syntax checks, tag lines as errors/warnings, and are interpreted by language service. This would effectively allow to enforce null checks with external library.

In fact I see the analyzers in TypeScript would be really great for other things too. There are really weird libraries out there, more so than to C#.

For anyone following this issue: I'm maintaining a library called monapt that lets you declare the nullability of a variable. It includes Typescript definitions, so everything is compile-time checked.

Feedback welcome!

I just read through the whole thread.

I guess the proposal should use non-voidable and voidable terms, because void in TS spec is a type for the null and undefined value. (I assume the proposal also covers undefined value :smile: )

I also agree access undefined or null exception is root of all evil in programming adding this feature will save countless hours for people.

Please add this! And it would be best if this became a feature I could pass a flag to make it the default. It would save a lot of debugging hell for a lot of people.

While I can agree that ADTs can be used in place of nullable types; how can we be sure that the ADT we pass isn't null itself? Any type in TS can be null, including ADTs, right? I see it as a major flaw in thinking about ADTs as a solution to the problem of non-nullable (non-voidable) types. ADTs only work as well as they do in languages which allow (or forbid) non-nullable types.

Another key issue is library definitions. I might have a library which expects a string as the argument, but the TS compiler can type check passing null to the function! That's just not right...

I see it as a major flaw in thinking about ADTs as a solution to the problem...

1. get ADT's available through a design pattern (due to the lack of native
   support from TypeScript)
2. forbid the null keyword
3. guard all places where nulls can leak in to your code from the outside
4. enjoy the null problem gone for good

On our project we managed to do steps 1, 2 and 3. Guess what we are doing
now.

@aleksey-bykov

How do you do (2) with undefined? It can arise in a variety of situations that don't involve the undefined keyword: uninitialized class members, optional fields, missing return statements in conditional branches...

Compare typescript with flowtype. At least flow deals with most of the cases.

Also, if you're willing to say "Forget about the common idioms in the language. I don't care, I will insulate myself from the rest of the world", then you're probably better off using purescript.

It can arise in a variety of situations that don't involve the undefined keyword...

• uninitialized class members - classes forbidden
• optional fields - optional fields/parameters forbidden
• missing return statements - a custom tslint rule that makes sure that all execution paths return

better off using purescript

• i wish but it the code it generates concerns performance the least

@aleksey-bykov its funny that you mention performance, because replacing nullable types with ADTs impose significant cpu and memory overhead compared to just enforcing null checks (like flowtype). Same goes for not using classes (can be prohibitively expensive if you instantiate lots of objects with lots of methods on them)

You mention giving up optional fields but they're used by so many JS libraries. What did you do to deal with those libraries?

You also mention not using classes. I suppose you also avoid libraries that rely (or will rely) on classes (like e.g. React)?

In any case, I don't see a reason to give up on so many features when a perfectly reasonable solution (that actually fits the underlying untyped language) is most likely possible to implement.

its funny that you think that the sole purpose of ADT's is for representing a missing value that would have been otherwise encoded by null

i'd rather say that having the "null" problem gone (and classes too) is a byproduct of all good things ADT's bring us

addressing your curiosity, for performance critical pieces like tight loops and large data structures we use so called Nullable<a> abstraction by fooling TypeScript into thinking that it deals with a wrapped value, but in fact (at runtime) such value is just a primitive that is allowed of taking nulls, there is special set of operations on Nullable's that prevents that null from leaking

let me know if you want to know the details

interface Nullable<a> {
    'a nullable': Nullable<a>;
    'uses a': a;
}
/*  the following `toNullable` function is just for illustration, we don't use it in our code,
    because there are no values capable of holding naked null roaming around,
    instead we just alter the definition of all unsafe external interfaces:
    // before
    interface Array<T> {
       find(callback: (value: T, index: number, array: T[]) => boolean, thisArg?: any): T;
    }
    // after
    interface Array<a> {
       find(callback: (value: a, index: number, array: a[]) => boolean, thisArg: any): Nullable<a>;
    }
*/
function toNullable<a>(value: a) : Nullable<a> {
    return <any>value;
}
function toValueOrDefault<a>(value: Nullable<a>, defaultValue: a)  : a {
    return value != null ? <any>value : defaultValue;
}

Why use a recursive type structure? 'a nullable': a should be sufficient, no?

I suppose you also have callFunctionWithNullableResult<T,U>(f: (T) => U, arg:T):Nullable<U> (including all other overloads for functions with different arity) to deal with all external functions that return nulls?

And if the null keyword is forbidden by a linter, how do you get a "Nothing" stored in a nullable? do you special-case toNullable(null)?

I know what algebraic datatypes are. Can you give me an instance (other than exhaustiveness checks and the clunkiness) where ADTs (or rather, sum types) + pattern matching can do something that typescript's unions + user defined type guards cannot do?

Why use a recursive type structure? 'a nullable': a should be sufficient, no?

well, in this example it is enough, but doing it like this overloads the purpose of such field, which serves 2 distinct cases:

• to turn type into nominal (the filed name in your example): https://gist.github.com/aleksey-bykov/0ab85f0b5e83fc848f85
• to make it aware of a generic type parameter so it is accounted for as far as the surface of the object (type of the value in your example): https://github.com/Microsoft/TypeScript/issues/468

i personally hate overloaded meaning this is why i go with 2 separate pseudo fields where each solves a separate problem

I suppose you also have callFunctionWithNullableResult(f: T -> U, arg:T) => Nullable