why does initialization narrow type?

[zpdDG4gta8XKpMCd]

nightly build

"compilerOptions": {
        "module": "amd",
        "moduleResolution": "classic",
        "noEmitOnError": true,
        "allowUnreachableCode": false,
        "allowUnusedLabels": false,
        "outDir": "./built",
        "noResolve": true,
        "noImplicitAny": true,
        "noImplicitReturns": true,
        "forceConsistentCasingInFileNames": true,
        "noFallthroughCasesInSwitch": true,
        "target": "es5"
        // "strictNullChecks": true
    }

export type Optional<a> = Some<a> | None;

export interface None { readonly none: string; }
export interface Some<a> { readonly some: a; }

export const none : None = { none: '' };

export function isSome<a>(value: Optional<a>): value is Some<a> {
    return 'some' in value;
}

export function fn<r>(): void {
    let result: Optional<r> = none;
    isSome(result)
        ? result.some
        : undefined
}

[malibuzios]

(Tested on 1.9.0-dev.20160507)

I believe what is happening here is similar to this much simpler example:

let x: number | string = 1234;

if (typeof x === "string") {
    x; // x has type 'nothing'
}

x was declared with the union type number | string, and was assigned a number. Flow analysis has correctly predicted that its actual type right before entering the if (typeof x conditional was number.

The program then went to test if its type was string and a narrowing was applied through the guard. Since flow analysis started with the assumption it was a number, the option of it being a either a number or a string in the body of the conditional had been already discarded, and the type that remained was the empty union type nothing.

In the example you gave, this function was used as a user-defined guard for the target type Some<T> and the source union Some<T> | None:

export function isSome<T>(value: Some<T> | None): value is Some<T> {
   //..
}

And the guard was applied in a similar circumstance:

let result: Some<T> | None = None; // Flow analysis now assumes the type is 'None'

if (isSome(result)) { // The option of it being 'None' is removed here
    result; // 'result' gets type 'nothing'
}

[zpdDG4gta8XKpMCd]

you might be right, but the flow analysis should not ignore the explicit type annotations result: Some<T> | None

[malibuzios]

The idea here, I believe, is that despite the fact that flow analysis uses unsound assumptions and is not really 'perfect' in its predictions (e.g. it doesn't currently account to assignment of captured variables by called functions), it is still somehow 'loyal' to its own idea of the execution of code. It predicted that the if block would never be executed so it used the nothing type there instead of string (which I believe it could and would also be technically correct).

let x: number | string = 1234; // flow analysis narrowed from 'number | string' to 'number'

if (typeof x === "string") { // flow analysis narrowed from 'number' to 'nothing'
    x; // x has type 'nothing'
}

My understanding is that nothing is used as a signifier for an 'error' state, to 'alert' the programmer when something went wrong from the point of view of the 'unsound' type system, not necessarily in run-time - where the if block could have actually been entered and executed perfectly fine, and x would indeed have the type string (I'm not necessarily referring to this particular example, though).

I have also tried to observe and suggest improvements for flow analysis in an even more 'extreme' state: where nothing is even assumed as the beginning point, more in this issue.

Edits: rephrased a bit.

[zpdDG4gta8XKpMCd]

i understand your reasoning, i am questioning the premise of the apparent fact that despite being explicitly said that result at the point of its declaration can be either Some<r> or None the flow analysis ignores it and fails short immediately

[mhegazy]

as @malibuzious noted, this is behaving as expected.

let result: Optional<r> = none;

beahaves as:

let result: Optional<r> = none;
result; // Some<r> | None | undefined
result = none;
result; // None

To achieve the result you want case the value, i.e.:

let result = <Optional<r>>none;

[zpdDG4gta8XKpMCd]

this is just rediculous

favoring let result = <Optional<r>>none over let result: Optional<r> = none... how can i unsee it

[zpdDG4gta8XKpMCd]

i hope there will be a flag to turn the flow analysis off because its' going to break 75% of our code base

[zpdDG4gta8XKpMCd]

we all understand that let result = <Optional<r>> none is semantically different (and not in a good way) from let result: Optional<r> = none, don't we?

[mhegazy]

i hope there will be a flag to turn the flow analysis off because its' going to break 75% of our code base

so is this the pattern you are using?

let result: Optional<r> = none;

initalizeResult();

if (isSome()) {
 .... 
}

See related discussion in #8381

[zpdDG4gta8XKpMCd]

no, result here is a accumulator value for a fold/reduce like routine, so
we start it with a "zero" value (none in this case) then we step into a
loop where the accumulation happens and immediately hit this problem.

I intentionally left the original code outside to make it clean cut.
On May 7, 2016 4:04 PM, "Mohamed Hegazy" notifications@github.com wrote:

i hope there will be a flag to turn the flow analysis off because its'
going to break 75% of our code base

so is this the pattern you are using?

let result: Optional = none;

initalizeResult();
if (isSome()) {
....
}

See related discussion in #8381
#8381

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#8513 (comment)

[mhegazy]

I do not see the issue then. Can you post a more elaborated sample of the pattern you use?

[ahejlsberg]

Aleksey-Bykov Consider this example:

// Compile with --strictNullChecks
let x: string | number = "abc";
let len = x.length;  // Ok, x is known to be a string
x = 5;
let y = x * 10;  // Ok, x is known to be number
x = true;  // Error, boolean not assignable to string | number

Note that the type annotation specifies the upper type bound that must always be true for values assigned to the variable, but the whole purpose of control flow based type analysis is to track the more specific actual type of the variable. That's what is happening above. The compiler isn't ignoring anything.

If I understand you correctly, you're arguing that the first line should be an error? (i.e. that the compiler should ignore the assigned type and pretend that the current value is possibly a number.)

[myitcv]

Anders Hejlsberg (@ahejlsberg) the "change" here is that previously the following would have been an error:

// From Playground (pre control flow)
let x: string | number = "abc";
let len = x.length;   // error: property 'length' does not exist on type 'string | number'

If anyone relied on/expected this to be an error before, it is no longer an error with control flow analysis as implemented and hence is breaking to my mind.

Have to agree with Aleksey-Bykov (assuming we are unhappy with the same thing?!). I declare types on variables to help enforce things (i.e. expect errors in certain situations) as much as I look to ask "what can I do?"

If I declare a variable as type string | number:

let x: string | number;

then I expect the method/property set to be the intersection of string and number

Is there any reason control flow analysis has not been put behind a flag to turn it on?