I find myself often repeating this boilerplate:

if (obj.member !is null)
{
	if (obj.member.nested !is null)
	{
		if (obj.member.nested.val !is null)
		{
			writeln(obj.member.nested.val);
		}
	}
}

I have to admit it's a little frustrating when you see swift's ?. syntax notation, it would be a little more practical to be able to write

writeln(obj.member?.nested?.val);


Based on http://appventure.me/2014/06/13/swift-optionals-made-simple/


Any thoughts?

On Wednesday, 18 June 2014 at 15:42:04 UTC, Etienne wrote:
> I find myself often repeating this boilerplate:
>
> if (obj.member !is null)
> {
> 	if (obj.member.nested !is null)
> 	{
> 		if (obj.member.nested.val !is null)
> 		{
> 			writeln(obj.member.nested.val);
> 		}
> 	}
> }
>
> I have to admit it's a little frustrating when you see swift's ?. syntax notation, it would be a little more practical to be able to write
>
> writeln(obj.member?.nested?.val);
>
>
> Based on http://appventure.me/2014/06/13/swift-optionals-made-simple/
>
>
> Any thoughts?

C# is getting the same syntax, and I remember there being some discussion about it here. It's somewhat useful I suppose, though I think it's made significantly more useful in C# with 'a ?? b' (a if a is not null, else b).

> C# is getting the same syntax, and I remember there being some
> discussion about it here. It's somewhat useful I suppose, though I think
> it's made significantly more useful in C# with 'a ?? b' (a if a is not
> null, else b).


I've seen too many bugs where you end up dereferencing a null pointer, also with the -> being replaced by . in D this is even more confusing when you switch a member from a pointer to a struct. The compiler could easily advise you to use the .? notation when you're moving in too deep into no man's land.

Etienne:

> writeln(obj.member?.nested?.val);

What about an approach like Scala instead?

Bye,
bearophile

On 2014-06-18 11:55 AM, bearophile wrote:
> Etienne:
>
>> writeln(obj.member?.nested?.val);
>
> What about an approach like Scala instead?
>
> Bye,
> bearophile

You mean like this?


http://stackoverflow.com/questions/1163393/best-scala-imitation-of-groovys-safe-dereference-operator

def ?[A](block: => A) =
  try { block } catch {
    case e: NullPointerException if e.getStackTrace()(2).getMethodName == "$qmark" => null
    case e => throw e
  }

val a = ?(b.c.d.e)

On 18/06/14 23:42, Etienne wrote:
> I find myself often repeating this boilerplate:
>
> if (obj.member !is null)
> {
>      if (obj.member.nested !is null)
>      {
>          if (obj.member.nested.val !is null)
>          {
>              writeln(obj.member.nested.val);
>          }
>      }
> }
>
> I have to admit it's a little frustrating when you see swift's ?. syntax
> notation, it would be a little more practical to be able to write
>
> writeln(obj.member?.nested?.val);
>
>
> Based on http://appventure.me/2014/06/13/swift-optionals-made-simple/
>
>
> Any thoughts?

I want non-null in the type system! To put a nullable reference into a non-null variable you need to check first, but from then on the compiler can ensure it's never null!

> I want non-null in the type system! To put a nullable reference into a
> non-null variable you need to check first, but from then on the compiler
> can ensure it's never null!

That would be great but useless for my situation involving some complex AST's

class AEntity
{
	Module head;
	string ident;
	Type type;
	AEntity typeInfo;
	AEntity[] members; // for definitions
	AEntity[] parameters; // if parameterized
...
}

It's very useful to descend through parts of a complex tree without adding plenty of bool checks

foreach (AEntity member; entity.members)
{
	if (member.typeInfo !is null)
	{
		AEntity curr = member;
		member.ident ~= member.typeInfo.ident;
		curr = member.typeInfo;
		while (curr.typeInfo !is null)
		{
			member.ident ~= "." ~ curr.typeInfo.ident;
			curr = curr.typeInfo;
		}
	}
}

On 6/18/14, 1:17 PM, Etienne wrote:
>> I want non-null in the type system! To put a nullable reference into a
>> non-null variable you need to check first, but from then on the compiler
>> can ensure it's never null!
>
> That would be great but useless for my situation involving some complex
> AST's
>
> class AEntity
> {
>      Module head;
>      string ident;
>      Type type;
>      AEntity typeInfo;
>      AEntity[] members; // for definitions
>      AEntity[] parameters; // if parameterized
> ...
> }
>
> It's very useful to descend through parts of a complex tree without
> adding plenty of bool checks
>
> foreach (AEntity member; entity.members)
> {
>      if (member.typeInfo !is null)
>      {
>          AEntity curr = member;
>          member.ident ~= member.typeInfo.ident;
>          curr = member.typeInfo;
>          while (curr.typeInfo !is null)
>          {
>              member.ident ~= "." ~ curr.typeInfo.ident;
>              curr = curr.typeInfo;
>          }
>      }
> }

But if you don't add the bool checks you might get segmentation fault. Or am I missing something?

> But if you don't add the bool checks you might get segmentation fault.
> Or am I missing something?
>

In D all pointers are zero-filled on initialization so it counts as a bool for me and null is the same as if you had a *.init

On Wednesday, 18 June 2014 at 15:42:04 UTC, Etienne wrote:
> I find myself often repeating this boilerplate:
>
> if (obj.member !is null)
> {
> 	if (obj.member.nested !is null)
> 	{
> 		if (obj.member.nested.val !is null)
> 		{
> 			writeln(obj.member.nested.val);
> 		}
> 	}
> }
>
> I have to admit it's a little frustrating when you see swift's ?. syntax notation, it would be a little more practical to be able to write
>
> writeln(obj.member?.nested?.val);
>
>
> Based on http://appventure.me/2014/06/13/swift-optionals-made-simple/
>
>
> Any thoughts?

Would be great! I think though, one could simplify it, you don't need multiple ?'s(one would do)

if (?obj.member.nested.val == null)
{
...
}

?object returns null if the object is null, even if it is dereferenced.

possibly a better syntax would be

if (??obj.member.nested.val == null)

If used as a rval one could have

auto x = ??obj.member.nested.val;

x is null if obj, obj.member, or obj.member.nested is null. Else obj.member.nested.val.

I'm just curious who is going to add the the code to D?

If you don't like ?? (confusing it with the null-coalescing operator) then what about ?*, *?, ?&, &?, ???, etc...