Hi

See: https://optional.dub.pm

I've totally revamped the Optional type and am now quite happy with. It has a range interface and safe dispatching and can be used to 1) avoid null dereferencing, 2) have non-null guarantees, and 3) show clear intent where there may or may not be a value. It's also @nogc and @safe and mutation of the original object during safe dispatching works as well.

Some code examples:

===
import optional;
import std.stdio: writeln;

class Residence {
    auto numberOfRooms = 4;
}
class Person {
    Optional!Residence residence;
}

auto john = some(new Person());

john.dispatch.residence.dispatch.numberOfRooms.writeln; // safe, prints "[]"
john.dispatch.residence = new Residence();
john.dispatch.residence.dispatch.numberOfRooms.writeln; // prints "[4]"

if (auto res = john.dispatch.residence.unwrap) {
    writeln(res.numberOfRooms); // safe, prints "4"
}
===

And since it's a range type as well, you can use it with phobos algos (and it provides some primitives found in e.g. scala)

===
import std.algorithm: each;

// Make a function that may or may not parse a string to an int
Optional!int toInt(string str) {
    import std.conv: to;
    scope(failure) return no!int;
    return some(str.to!int);
}

auto x = toInt("1").orElse(0);

toInt("1").each!writeln;

toInt("1").match!(
    (i) => writeln(i),
    () => writeln("nothing there"),
);
===

The readme contains a lot more details.

Some things that are on me list that I need to think about
- Consider a short form for "dispatch". Purely for convenience:
   e.g.: john.d.residence.d.numberOfRooms;
- Consider an auto dispatch (".autoDispatch"?), so that once you start a chain you don't need to write "dispatch again:
   e.g.: john.autoDispatch.residence.numberOfRooms;


Some reasonings for design:
- The dispatcher is a completely separate type because Optional is a range type and has it's own functions that would be impossible to call on a type T without unwrapping first.
- The "safe dispatcher" proxy contains NO functions so that it will never trample over a type T.


Cheers,
- Ali

On Thursday, 16 August 2018 at 12:25:14 UTC, aliak wrote:
> Hi
>
> See: https://optional.dub.pm

Looks great!

> auto john = some(new Person());

Would it also work to leave off the `some` here and skip the first `dispatch` in the following lines? (i.e., make `john` a `Person` rather than an `Optional!Person`)

On Thursday, 16 August 2018 at 15:38:50 UTC, Paul Backus wrote:
> On Thursday, 16 August 2018 at 12:25:14 UTC, aliak wrote:
>> Hi
>>
>> See: https://optional.dub.pm
>
> Looks great!
>
>> auto john = some(new Person());
>
> Would it also work to leave off the `some` here and skip the first `dispatch` in the following lines? (i.e., make `john` a `Person` rather than an `Optional!Person`)


Thanks!
And aye, it should work fine!

On Thursday, 16 August 2018 at 12:25:14 UTC, aliak wrote:
> It's also @nogc and @safe

No it's not. Not dispatching at least. Dunno why though. Seems safey is because taking an address. Nogc will have to look in to.

On Thursday, 16 August 2018 at 12:25:14 UTC, aliak wrote:
> Hi
>
> See: https://optional.dub.pm
>
> I've totally revamped the Optional type and am now quite happy with. It has a range interface and safe dispatching and can be used to 1) avoid null dereferencing, 2) have non-null guarantees, and 3) show clear intent where there may or may not be a value. It's also @nogc and @safe and mutation of the original object during safe dispatching works as well.
>

The readme.md page looks great. You might mention that it works with @nogc and @safe (I presume Optional and NotNull).

One question: Suppose there was a @weaksafe that has all the same features @safe except that it relaxed the requirement of "No taking the address of a local variable or function parameter." so that you could take the address of a NotNull variable. Are there any reasons why this would be unsafe? I imagine NotNull requires some type of run-time checking, but other than that I don't see why not.

On Thursday, 16 August 2018 at 18:10:38 UTC, jmh530 wrote:
> On Thursday, 16 August 2018 at 12:25:14 UTC, aliak wrote:
>> Hi
>>
>> See: https://optional.dub.pm
>>
>> I've totally revamped the Optional type and am now quite happy with. It has a range interface and safe dispatching and can be used to 1) avoid null dereferencing, 2) have non-null guarantees, and 3) show clear intent where there may or may not be a value. It's also @nogc and @safe and mutation of the original object during safe dispatching works as well.
>>
>
> The readme.md page looks great. You might mention that it works with @nogc and @safe (I presume Optional and NotNull).
>
> One question: Suppose there was a @weaksafe that has all the same features @safe except that it relaxed the requirement of "No taking the address of a local variable or function parameter." so that you could take the address of a NotNull variable. Are there any reasons why this would be unsafe? I imagine NotNull requires some type of run-time checking, but other than that I don't see why not.

Actually "@weaksafe" already exists in the form of `@safe` + `-dip1000` - you can take the address of a local variable in `@safe` code and then you get a `scope`-ed pointer, which you're not allowed to escape.

On Friday, 17 August 2018 at 06:59:48 UTC, Petar Kirov [ZombineDev] wrote:
> On Thursday, 16 August 2018 at 18:10:38 UTC, jmh530 wrote:
>> On Thursday, 16 August 2018 at 12:25:14 UTC, aliak wrote:
>>> Hi
>>>
>>> See: https://optional.dub.pm
>>>
>>> I've totally revamped the Optional type and am now quite happy with. It has a range interface and safe dispatching and can be used to 1) avoid null dereferencing, 2) have non-null guarantees, and 3) show clear intent where there may or may not be a value. It's also @nogc and @safe and mutation of the original object during safe dispatching works as well.
>>>
>>
>> The readme.md page looks great. You might mention that it works with @nogc and @safe (I presume Optional and NotNull).
>>
>> One question: Suppose there was a @weaksafe that has all the same features @safe except that it relaxed the requirement of "No taking the address of a local variable or function parameter." so that you could take the address of a NotNull variable. Are there any reasons why this would be unsafe? I imagine NotNull requires some type of run-time checking, but other than that I don't see why not.
>
> Actually "@weaksafe" already exists in the form of `@safe` + `-dip1000` - you can take the address of a local variable in `@safe` code and then you get a `scope`-ed pointer, which you're not allowed to escape.

Right! There's that. That would most certainly help here.

So the first non-safety part of Optional comes from the dispatch function. To support mutations, the pattern is basically:

struct Optional(T) {
  T value;
  auto dispatch() inout {
    return inout Dispatcher(&this);
  }
}

Now the thing is, the Dispatcher type is actually disabled on copying, construction and identity assignment. So I wonder if this can be marked @trusted in theory. Since the address never escapes from a Dispatcher object.

And the other part is when two addresses are compared (which is local only): https://github.com/aliak00/optional/blob/83edfef7130ec02992ec2986611718f80167234d/source/optional/dispatcher.d#L42

On Thursday, 16 August 2018 at 16:20:09 UTC, aliak wrote:
> On Thursday, 16 August 2018 at 12:25:14 UTC, aliak wrote:
>> It's also @nogc and @safe
>
> No it's not. Not dispatching at least. Dunno why though. Seems safey is because taking an address. Nogc will have to look in to.

Hello!

please, help, how can I use match in @nogc code:

import optional;

void main() @nogc {
    Optional!int i = 1;
    bool b = true;
    i.match!(
        (v) => b,
        () => false
    );
}

fails to compile:
source/app.d(3,6): Error: function `D main` is @nogc yet allocates closures with the GC
source/app.d(7,9):        app.main.__lambda1 closes over variable b at source/app.d(5,10)

Thanks!

On Monday, 20 August 2018 at 09:16:18 UTC, ikod wrote:
> On Thursday, 16 August 2018 at 16:20:09 UTC, aliak wrote:
>> On Thursday, 16 August 2018 at 12:25:14 UTC, aliak wrote:
>>> It's also @nogc and @safe
>>
>> No it's not. Not dispatching at least. Dunno why though. Seems safey is because taking an address. Nogc will have to look in to.
>
> Hello!
>
> please, help, how can I use match in @nogc code:
>
> import optional;
>
> void main() @nogc {
>     Optional!int i = 1;
>     bool b = true;
>     i.match!(
>         (v) => b,
>         () => false
>     );
> }
>
> fails to compile:
> source/app.d(3,6): Error: function `D main` is @nogc yet allocates closures with the GC
> source/app.d(7,9):        app.main.__lambda1 closes over variable b at source/app.d(5,10)
>
> Thanks!

Hi, it's because the lambda "(v) => b" allocates. Same would happen with any other function that takes an alias to a lambda and that lambda causes a closure allocation.

Changing this to "(int v) => b" seems to make the compiler infer @nogc though and it compiles.

But it's still a delegate, so I'm not sure why that works and not sure in which situations D infers a nogc delegate.

The same thing does not work for algorithm.map for e.g.

Cheers
- Ali

On Thursday, 16 August 2018 at 12:25:14 UTC, aliak wrote:
> Hi
>
> See: https://optional.dub.pm
>
> [...]

That looks pretty cool!
I added optional to run.dlang.io (e.g. https://run.dlang.io/is/912kVG) and the project tester (https://github.com/dlang/ci/pull/288).