Safe navigation operator executes members after "?." even if not needed

I’m submitting a … (check one with “x”)

• bug report
• feature request
• support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Current behavior Safe navigation operator can be used to prevent Angular from throwing errors, when trying to access object properties of objects that don’t exist.

E.g.

{{ contact?.name }}

Only evaluates name when contact is not null or undefined. This comes in handy when contact is something that is loaded asynchronously.

However, let’s say we have another object on contact

contact: {
  name: 'foo',
  address: {
    street: 'bar'
  }
}

If we want to access street in the template even though, contact is loaded asynchronously, we can use the safe navigation operator for that. But we need to apply it on every nested property because Angular doesn’t ignore the rest of an expression after a ?..

Here’s what we need to do to render street, even though, address is synchronous:

{{ contact?.address?.street }}

Expected/desired behavior

Angular should ignore member accesses after ?. inside expressions when the thing before the ?. is null or undefined. Or, in code, we should be able to simply do:

{{ contact?.address.street }}

Reproduction of the problem Plunk: http://plnkr.co/edit/TaoC2w0sSx1izwiqAoJQ?p=preview

Please tell us about your environment:

• Angular version: 2.0.0-rc.4
• Browser: all
• Language: TypeScript 1.9

[wardbell]

Hey … wait a second. The very wikipedia article you cite says that they ARE the same thing.

the safe navigation operator (also known as optional chaining operator, safe call operator, null-conditional operator)

It also cites (approvingly) the .net example.

More importantly, the other citations are MUTE on short-circuiting. I’m betting that at least some, if not all, of them implement short-circuiting.

And now I see that Pascal said essentially the same thing.

Please re-open and reconsider or at least offer a more compelling answer.

[wardbell]

I’m piling on. This isn’t just our opinion about how the “save navigation operator” AKA “null conditional operator” should work.

Here’s a primary source of this idea … .net of all places.

​The null-conditional operator exhibits short-circuiting behavior​ [emphasis mine], where an immediately following chain of member accesses, element accesses and invocations will only be executed if the original receiver was not null:

int? first = customers?[0].Orders.Count();

This example is essentially equivalent to:

int? first = (customers != null) ? customers[0].Orders.Count() : null;

Except that customers is only evaluated once. ​**None of the member accesses, element accesses and invocations immediately following the ? are executed unless customers has a non-null value.**​ [emphasis mine]

Of course null-conditional operators can themselves be chained, in case there is a need to check for null more than once in a chain:

int? first = customers?[0].Orders?.Count();