This needs to go in 1.11. Without it, non-null declarations on identifiers get split on lines, causing tslint to not be able to parse the line.

@j-f1

Thanks for contributing! :)

I'm curious, is the fact that tslint doesn't parse it the only issue with this? Let me preface it with the fact that I've never seen or written any code with it but the way it was originally printed looked clearer to me.

It feels weird to have the ! hanging at the end of the previous line. !. feels like an operator to me, not two distinct tokens.

It seemed typescript didn't mind it.

I thought this was important because it was a regression.

I also think the ! must go with the preceding thing as thats what it modifies.

In JavaScript, ?. needs to be as a single token otherwise it's not being parsed correctly.

SyntaxError: Unexpected token (1:5)
> 1 | a ? . b
    |     ^

Can you give what was the error message for tslint? We should definitely raise an issue to the project at least.

I'm curious, is the fact that tslint doesn't parse it the only issue with this?

It’s not just TSLint, it’s invalid TypeScript. TS parses it as:

foo;
!(<identifier with name === "">.bar())

That sounds like a bug! Could any of you two report it to the typescript repo?

This is the fix

@vjeux I don't think they should behave the same in this case.. I think ?. should follow the same rules as . they are both "accessing" something in the object

! is just type casting (a! or (a as B)) and doesn't need to be in a chain for that matter

(I think that's it, I don't really use TS or ?. so please correct me if I said something wrong)

My understanding is that !. means access or throw and ?. means access or return null. I view them as being the same operation.

From https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-0.html:

A new ! post-fix expression operator may be used to assert that its operand is non-null and non-undefined in contexts where the type checker is unable to conclude that fact. Specifically, the operation x! produces a value of the type of x with null and undefined excluded. Similar to type assertions of the forms <T>x and x as T, the ! non-null assertion operator is simply removed in the emitted JavaScript code.

Makes sense, thanks for the explanation @duailibe!

I would still like to see an issue reported.

a!
  .b

and

a
  !.b

should likely parse the same way.

I'm perfectly fine with the second form being an error.

Ohhh, okay I re-read @j-f1 explanation and this is because of automatic semi-colon insertion. Because it's a post-fix operator and not an infix one with the dot, then it changes the parsing tree. I doubt that they'll want to change the ASI rules to have ! behave differently. ? is already checked differently because it's used for ?:.

@ericanderson thanks for doing this! I just wanted to make sure that we were doing the right thing.