I was looking for a way to avoid null checks everywhere. I was checking the Null object pattern, or use something like enforce pattern, or even if I could make a new operator and implement something like C#'s .? operator, that Java was going to have one but they refused[1] (doesn't behave exactly as C#'s actually), Kotlin also got something in this area[2]

What some D ways to avoid those checks?

[1]: https://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000047.html
[2]: https://kotlinlang.org/docs/reference/null-safety.html#safe-calls

Currently I'm with this:

auto ref ifNotNull(T, T2)(T lhs, lazy T2 rhs)
{
    if(lhs) {
        rhs();
    }
    return lhs;
}


far from good. I wish there was a way to create a new operator so I would make .? similar to C#'s but would evaluate the left-handed side only if it's null and do nothing otherwise (C#'s evaluate to null, probably due to lack of control of flow structure, which isn't possible within a source code, only from compiler's side, as far i know)

On Tuesday, 12 January 2021 at 21:37:11 UTC, Jack wrote:
> I was looking for a way to avoid null checks everywhere. I was checking the Null object pattern, or use something like enforce pattern, or even if I could make a new operator and implement something like C#'s .? operator, that Java was going to have one but they refused[1] (doesn't behave exactly as C#'s actually), Kotlin also got something in this area[2]
>
> What some D ways to avoid those checks?
>
> [1]: https://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000047.html
> [2]: https://kotlinlang.org/docs/reference/null-safety.html#safe-calls

Personally, I really like functional orientation (MayBe, None, Some... and pattern matching) avoiding the use of null, but D is a "system" language compatible with C and null is mandatory.

Some months ago I wrote an utility template to simulate the ?. mechanism.


The resulting syntax:

  class Person
  {
    string name;
    Person father;

    this(string name, Person father){	
      this.name=name;
      this.father=father;
    }
  }

 Person p = new Person("Peter", new Person("John", null));
 assert( p.d!"father".d!"father".d!"name".get is null);
 assert( p.d!"father".d!"name".get == "John");
 assert( p.d!"father".d!"name".d!"length".get(0) == 4);
 assert( p.d!"father".d!"father".d!"name".d!"length".get(0) == 0);
 assert( (cast(Person) null).d!"father".d!"father".d!"father".get is null);


That is a "compact" version of a first solution using lambdas

 assert( dot(p).dot(a=>a.father).dot(a=>a.father).dot(a=>a.name).dot(a=>a.length).get(0) == 0);

Find more details here:

https://run.dlang.io/gist/392c06e745d1a35df71084ce4d29fed7

On Wednesday, 13 January 2021 at 09:02:37 UTC, ddcovery wrote:
> Find more details here:
>
> https://run.dlang.io/gist/392c06e745d1a35df71084ce4d29fed7

Ups... it seems that the link is not working (it is the first time I try to generate a dalng/gist link... I'm not sure if this can really be done)...

I will create an example github project tonight... may be it can help you.

On Tuesday, 12 January 2021 at 21:37:11 UTC, Jack wrote:
> I was looking for a way to avoid null checks everywhere. I was checking the Null object pattern, or use something like enforce pattern, or even if I could make a new operator and implement something like C#'s .? operator, that Java was going to have one but they refused[1] (doesn't behave exactly as C#'s actually), Kotlin also got something in this area[2]
>
> What some D ways to avoid those checks?
>
> [1]: https://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000047.html
> [2]: https://kotlinlang.org/docs/reference/null-safety.html#safe-calls

Hi Jack,

I have created this example implementation of the "Null safety" pattern using templates in D:

https://github.com/ddcovery/d_null_safety

It is, basically, a monad (functional programming orientation)  with some syntax sugar taking advantage of the power of templates in D.

On 12.01.21 22:37, Jack wrote:
> I was looking for a way to avoid null checks everywhere. I was checking the Null object pattern, or use something like enforce pattern, or even if I could make a new operator and implement something like C#'s .? operator, that Java was going to have one but they refused[1] (doesn't behave exactly as C#'s actually), Kotlin also got something in this area[2]
> 
> What some D ways to avoid those checks?
> 
> [1]: https://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000047.html
> [2]: https://kotlinlang.org/docs/reference/null-safety.html#safe-calls
Did you have a look at https://code.dlang.org/packages/optional?
Especially https://aliak00.github.io/optional/optional/oc/oc.html might go in the right direction.


Kind regards,
Christian

On Thursday, 14 January 2021 at 21:49:41 UTC, Christian Köstlin wrote:
> ...
> Did you have a look at https://code.dlang.org/packages/optional?
> Especially https://aliak00.github.io/optional/optional/oc/oc.html might go in the right direction.
>
>
> Kind regards,
> Christian

Thats nice!!!

I was commenting the need of a MayBe (some/none) monad compatible with Ranges (as an alternative to Nullable!T ) in  https://forum.dlang.org/post/gxapatzfkoigcdhrdztv@forum.dlang.org

Thanks a lot Christian.