On Tuesday, 23 February 2016 at 22:03:32 UTC, Xinok wrote:
> On Tuesday, 23 February 2016 at 19:43:43 UTC, rsw0x wrote:
>> ...
>> How does this differ from the example I gave where the branch is only taken if the pointer is non-null?
>
> D doesn't prevent you from dereferencing a null pointer whereas these scenarios should be impossible in Kotlin as well as Rust. Case and point, this code compiles without issue but crashes at runtime:
>
>     int* foo()
>     {
>         return null;
>     }
>
>     void main()
>     {
>         if(int* ptr = new int)
>         {
>             ptr = foo();  // Whoops...
>             *ptr = 35;    // Crash
>         }
>     }
>
> In D, pointers and reference types can spontaneously become null under almost any context. That's the difference.

The idea is to match non-null pointers, this is how you do it:

    int* foo()
    {
        return null;
    }

    void main()
    {
        if(int* ptr = foo())
        {
            *ptr = 35;    // no crash
        }
    }

On 02/23/2016 09:58 AM, Xinok wrote:
>
> Option<T> is an enum type in Rust (i.e. algebraic data type). The Rust
> compiler forces you to check all possible cases so you can't use it
> improperly. So you would have to use something like pattern matching or
> "if let" to check the state.
>
> https://doc.rust-lang.org/book/match.html#matching-on-enums

Probably we can do the same in a library: never allow the value out of an Option, but provide a visitor with two aliases (ham/spam). There was a related PR in Phobos, wasn't there? -- Andrei

On Wednesday, 24 February 2016 at 14:50:37 UTC, Andrei Alexandrescu wrote:
> Probably we can do the same in a library: never allow the value out of an Option, but provide a visitor with two aliases (ham/spam).

Rust provides value accessor for Option: https://doc.rust-lang.org/stable/std/option/enum.Option.html#method.unwrap

On Wednesday, 24 February 2016 at 14:50:37 UTC, Andrei Alexandrescu wrote:
> There was a related PR in Phobos, wasn't there?

https://forum.dlang.org/post/n0j9nj$10e9$1@digitalmars.com - probably this.

On my experience programming using Optional's functional interfaces is more reliable then explicit logic, so in case when we have value semantic and Optional then Kotlin's approach is not very useful.
My old experiments about this (obviously java-inspired): optional.d

import std.typecons;
import std.stdio;

Nullable!T Optional(T)(){ return Nullable!T(); }
Nullable!T Optional(T)(T value){ return Nullable!T(value); }
Nullable!OUT map(IN, OUT)(Nullable!IN n, OUT delegate(IN) fn)
{
    return n.isNull() ? Nullable!OUT() : Nullable!OUT(fn(n.get()));
}
T orElse(T)(Nullable!T n, T value){ return n.isNull() ? value : n.get(); }
void ifPresent(T)(Nullable!T n, void delegate(T) fn){ if(!n.isNull()) fn(n.get()); }
void ifPresent(T)(Nullable!T n, void function(T) fn){ if(!n.isNull()) fn(n.get()); }
bool isPresent(T)(Nullable!T n){ return !n.isNull(); }
Nullable!T coalesce(T)(Nullable!T n, Nullable!T other){ return n.isNull() ? other : n; }



unittest
{
 assert(Optional!string().isNull());
 assert(Optional!string("asd").isPresent());
 assert(Optional!string("asd").map((string v) => v~"$") == "asd$");
 assert(Optional!string().map((string v) => v~"$").isNull());
 assert(Optional!string("true").map((string v) => v=="1" || v=="true").orElse(false) == true);
 assert(Optional!string().coalesce(Optional!string("test")) == "test");
 assert(Optional!string("test1").coalesce(Optional!string("test2")) == "test1");

 string a="-";
 Optional!string("A").ifPresent((string b){a=b;});
 Optional!string().ifPresent((string b){a=b;});
 assert(a == "A");

}