Apparently C# will get it in the next version.
http://blogs.msdn.com/b/jerrynixon/archive/2014/02/26/at-last-c-is-getting-sometimes-called-the-safe-navigation-operator.aspx

What do you think how well would this work in D2 ?

On Thursday, 27 February 2014 at 13:27:14 UTC, Remo wrote:
>
> Apparently C# will get it in the next version.
> http://blogs.msdn.com/b/jerrynixon/archive/2014/02/26/at-last-c-is-getting-sometimes-called-the-safe-navigation-operator.aspx
>
> What do you think how well would this work in D2 ?


I was just thinking to create this topic but you did first, haha.
I like that, to me +1 for implement.

On Thursday, 27 February 2014 at 13:27:14 UTC, Remo wrote:
>
> Apparently C# will get it in the next version.
> http://blogs.msdn.com/b/jerrynixon/archive/2014/02/26/at-last-c-is-getting-sometimes-called-the-safe-navigation-operator.aspx
>
> What do you think how well would this work in D2 ?

I like it. At my previous job, I extended std.json with an array index operator just to end up replacing it with a variadic getter to get around the problem of incomplete paths. Like that, there are some ways to get around this sort of issue, but I wouldn't complain about having it right out of the box.

Perhaps there should also be a ?[] operator.

foo?["a"]?[0]?["llama"]

On Thursday, 27 February 2014 at 13:27:14 UTC, Remo wrote:
>
> Apparently C# will get it in the next version.
> http://blogs.msdn.com/b/jerrynixon/archive/2014/02/26/at-last-c-is-getting-sometimes-called-the-safe-navigation-operator.aspx
>
> What do you think how well would this work in D2 ?

Wish I could locate bearophile's post on the topic, sadly ?. isn't easy to search for.

On Thursday, 27 February 2014 at 13:27:14 UTC, Remo wrote:
>
> Apparently C# will get it in the next version.
> http://blogs.msdn.com/b/jerrynixon/archive/2014/02/26/at-last-c-is-getting-sometimes-called-the-safe-navigation-operator.aspx
>
> What do you think how well would this work in D2 ?

D doesn't need this, you can implement monadic null checking in the library:

http://forum.dlang.org/post/kcrqyvddilteyhyygifc@forum.dlang.org

There's no need for a special operator for this. See the other posts in that thread for more information.

Robert

On Thursday, 27 February 2014 at 16:08:26 UTC, Robert Clipsham wrote:
> D doesn't need this, you can implement monadic null checking in the library:

By that argument, I can implement anything that D can do in assembler, hence I don't need D.

On Thursday, 27 February 2014 at 16:32:18 UTC, Chris Williams wrote:
> On Thursday, 27 February 2014 at 16:08:26 UTC, Robert Clipsham wrote:
>> D doesn't need this, you can implement monadic null checking in the library:
>
> By that argument, I can implement anything that D can do in assembler, hence I don't need D.

I'm not sure I understand your point. I'm simply stating that in D, right now, without adding any complexity to the language, you can do:

just(myObject).method1().method2().method3()

Which would have the same effect as:

myObject?.method1()?.method2()?.method3()

in C#. Is a special operator really needed for this?

Robert

On Thursday, 27 February 2014 at 17:02:02 UTC, Robert Clipsham wrote:
> On Thursday, 27 February 2014 at 16:32:18 UTC, Chris Williams wrote:
>> On Thursday, 27 February 2014 at 16:08:26 UTC, Robert Clipsham wrote:
>>> D doesn't need this, you can implement monadic null checking in the library:
>>
>> By that argument, I can implement anything that D can do in assembler, hence I don't need D.
>
> I'm not sure I understand your point. I'm simply stating that in D, right now, without adding any complexity to the language, you can do:
>
> just(myObject).method1().method2().method3()

You can't do that. You're reducing your example code - which was several dozen lines and only applied to objects for which you had added the special handler code - to the end result. After you've laid the framework for doing this, yes, you can do it. But there's a bunch of work that has to go into it before you get to that point. (Also, your implementation is far less efficient than something which rewrites the code as a bunch of nested "if (not null)" checks.)

If your argument was that there are more important things for the compiler team to work on, or that the syntax of the language was already large enough without adding more things for people to remember, then sure. But if we lived under the premise that there's no reason to add features to a compiler that abstract code down into a simpler syntax, then we'd have never developed variables or functions.

On Thursday, 27 February 2014 at 17:25:22 UTC, Chris Williams wrote:
>> just(myObject).method1().method2().method3()
>
> You can't do that. You're reducing your example code - which was several dozen lines and only applied to objects for which you had added the special handler code - to the end result. After you've laid the framework for doing this, yes, you can do it. But there's a bunch of work that has to go into it before you get to that point. (Also, your implementation is far less efficient than something which rewrites the code as a bunch of nested "if (not null)" checks.)
>
> If your argument was that there are more important things for the compiler team to work on, or that the syntax of the language was already large enough without adding more things for people to remember, then sure. But if we lived under the premise that there's no reason to add features to a compiler that abstract code down into a simpler syntax, then we'd have never developed variables or functions.

Most of the code I posted would be hidden away in a library, and will work with any type with methods or UDFs. I'll admit it is incomplete (no implicit casting to the original return types for example), but it is possible. End user code would be exactly as that line is. I haven't checked the assembly, but given the simplicity of the generated code I'm fairly certain it will optimise to the same as the if/else chain (feel free to prove me wrong :)).

Robert

On Thursday, 27 February 2014 at 13:27:14 UTC, Remo wrote:
>
> Apparently C# will get it in the next version.
> http://blogs.msdn.com/b/jerrynixon/archive/2014/02/26/at-last-c-is-getting-sometimes-called-the-safe-navigation-operator.aspx
>
> What do you think how well would this work in D2 ?

Chaining . operation is a code smell to begin with, and having
everything nullable is dubious as well. This is fixing a problem
that shouldn't exists to begin with.