Binding patterns should imply non-nullability

[yuit]

TypeScript Version: master-build
As originally suggested by @shovon in comment in additional of passing undefined/null in destructing parameter as suggested by the comment, destructing, in general, should never be allow undefined or null
Code

// All should be error
var {} = undefined;
var {} = null;
var [] = undefined;
var [] = null;

function one ({}) {}
function two([]) {}
function three({foo: string, bar: number}) {}
function four([a, b]: number[]) {}
function five({} = undefined) {}
function six([] = undefined) {}
one(undefined);
one(null)
two(undefined);
two(null);
three(undefined);
three(null);
four(undefined):
four(null);
five(undefined);
five(null);
six(undefined);
six(null);

// This is ok
function foo({} = {}) {}
function bar([] = []) {}
foo(undefined);
foo(null);
bar(undefined);
bar(null);

[shovon]

@DanielRosenwasser @yuit is this not slated for TypeScript 2.0?

[mhegazy]

All the function calls are already handled with --strictNullChecks. outside --strictNullChecks mode, null and undefined are valid input for these functions, do not see why we should disallow that. this is analogs to var x: {} = undefined, which is allowed.

The first set of var declarations are not flagged. but the empty destructing patters are are esoteric at best. var {a} = undefined is again flagged under --strictNullChecks.

I do not think we should add the concept of nullablity if --strictNullChecks is not set.