On Tuesday, 10 December 2013 at 20:35:08 UTC, Namespace wrote:
> I love Monadic null checking. Would be great if D would have it.

+1 on Monadic null checking. Do miss it from Groovy.
For me at least its the only thing on that list that I think D could really use.

On Tuesday, 10 December 2013 at 18:58:01 UTC, Suliman wrote:
> Maybe it would be possible to get some good idea from next version of C#
> It's only ideas about next version, but new future maybe next: http://damieng.com/blog/2013/12/09/probable-c-6-0-features-illustrated

Regarding #1 (Primary Constructors), I think the feature has limited usefulness which doesn't deserve a presence in the language and it would serve to confuse newbies who weren't aware of that feature. I prefer to consolidate existing features and make them more flexible to serve other purposes. For example, an old idea of mine is a syntax like this (assuming D had Python-style tuples):

this.(x, y) = (x, y);

The syntax would generate a tuple from members of this. Similarly, one could also generate arrays or dictionaries by writing this.[x, y].

Regarding #9, I see it's uses, but I wonder if it would be a good idea to implement it. My initial thoughts are that it would make grep'ing for declarations more difficult and I think it would actually make code more difficult to read. Also, due to order of evaluation, you couldn't use the variable until after the statement in which it's declared, e.g.:

x + foo(out int x)

On 12/10/2013 3:53 PM, Ary Borenszweig wrote:
> BTW, the other day I friend tried to explain me monads
> and he realized couldn't understand them himself

The best way to learn something is to try to explain it to someone else.

On 2013-12-11 00:21, Idan Arye wrote:
>       if(int b=a.tryParse!int()){
>           //some code that uses `b`
>       }
>
> if `a` is "0" we won't enter the then-clause even though we managed to
> parse. This is why we don't have this `tryParse` function in D...

Not just that - how would you signal that a is an invalid value? Throw an exception?

A solution would be:

  if (Option!int b = a.tryParse!int) {
    // Use b in here.
  }

--
  Simen

On 2013-12-10 21:35, Namespace wrote:
> I love Monadic null checking. Would be great if D would have it.

Wouldn't that be possible to implement as a library function, at least the "points?.FirstOrDefault()?.X" part. Although it won't look as pretty.

BTW, how is that handled in a language where everything is not an object and can be null?

-- 
/Jacob Carlborg

On Tuesday, 10 December 2013 at 20:35:08 UTC, Namespace wrote:
> I love Monadic null checking. Would be great if D would have it.

Doesn't need to be a language feature - you can implement it as a library type. Here's a quick hacked together maybe monad:

----
import std.stdio;

struct Maybe(T)
{
    private T val = null;

    this(T t)
    {
        val = t;
    }

    auto opDispatch(string method, U...)(U params)
    {
        alias typeof(mixin("val." ~ method ~ "(params)")) retType;
        if (val) {
            mixin("return Maybe!(" ~ retType.stringof ~ ")(val." ~ method ~ "(params));");
        }
        return nothing!retType();
    }
}

Maybe!T just(T)(T t)
{
    return Maybe!T(t);
}

Maybe!T nothing(T)()
{
    return Maybe!T();
}

class Foo
{
    Bar retNull()
    {
        writeln("foo null");
        return null;
    }

    Bar notNull()
    {
        writeln("foo not null");
        return new Bar();
    }
}

class Bar
{
    Foo retNull()
    {
        writeln("bar null");
        return null;
    }

    Foo notNull()
    {
        writeln("bar not null");
        return new Foo();
    }
}

void main()
{
    auto maybe = just(new Foo);
    maybe.notNull().notNull().notNull().retNull().notNull();
}

----

On Wednesday, 11 December 2013 at 13:40:22 UTC, Robert Clipsham wrote:
> On Tuesday, 10 December 2013 at 20:35:08 UTC, Namespace wrote:
>> I love Monadic null checking. Would be great if D would have it.
>
> Doesn't need to be a language feature - you can implement it as a library type. Here's a quick hacked together maybe monad:
>
> ----
> import std.stdio;
>
> struct Maybe(T)
> {
>     private T val = null;
>
>     this(T t)
>     {
>         val = t;
>     }
>
>     auto opDispatch(string method, U...)(U params)
>     {
>         alias typeof(mixin("val." ~ method ~ "(params)")) retType;
>         if (val) {
>             mixin("return Maybe!(" ~ retType.stringof ~ ")(val." ~ method ~ "(params));");
>         }
>         return nothing!retType();
>     }
> }
>
> Maybe!T just(T)(T t)
> {
>     return Maybe!T(t);
> }
>
> Maybe!T nothing(T)()
> {
>     return Maybe!T();
> }
>
> class Foo
> {
>     Bar retNull()
>     {
>         writeln("foo null");
>         return null;
>     }
>
>     Bar notNull()
>     {
>         writeln("foo not null");
>         return new Bar();
>     }
> }
>
> class Bar
> {
>     Foo retNull()
>     {
>         writeln("bar null");
>         return null;
>     }
>
>     Foo notNull()
>     {
>         writeln("bar not null");
>         return new Foo();
>     }
> }
>
> void main()
> {
>     auto maybe = just(new Foo);
>     maybe.notNull().notNull().notNull().retNull().notNull();
> }
>
> ----

Now define map,bind,join. It quickly gets ugly.

https://bitbucket.org/qznc/d-monad/src/5b9d41c611093db74485b017a72473447f8d5595/generic.d?at=master

On Tuesday, 10 December 2013 at 23:53:25 UTC, Ary Borenszweig wrote:
> On 12/10/13 5:35 PM, Namespace wrote:
>> I love Monadic null checking. Would be great if D would have it.
>
> What does a monad have to do with that?
>
> (just out of curiosity... BTW, the other day I friend tried to explain me monads and he realized couldn't understand them himself)

Monads suffer from the same problem algebra, templates and many other things do in that they have a scary name and are often poorly explained.

They way I like to think of monads is simply a box that performs computations. They have two methods, bind and return. return lets you put a value into the box, and bind lets you call some function with the value that's in the box. Probably the simplest example is the maybe monad ("monadic null checking"). The idea is to let you change something like this:
----
auto a = ...;
if (a != null) {
    auto b = a.foo();
    if (b != null) {
        b.bar();
        // And so on
    }
}
----
Into:
----
a.foo().bar();
----

Here, the bind and return methods might look something like:
----
// "return" function
Maybe!Foo ret(Foo f) {
    return just(f);
}
auto bind(Maybe!Foo thing, Foo function(Foo) fn) {
    if(thing) {
        return ret(fn(thing));
    }
    return nothing();
}
----
There are two functions here for getting instances of maybe - nothing and just. Nothing says "I don't have a value" and just says "I have a value". The bind method then simply says "if I have a value, call the function, otherwise just return nothing". The code above would be used as follows:
----
bind(bind(a, &foo), &bar);
----
With a bit of magic you can get rid of the overhead of function pointers and allow it to work with other function types, but it shows the general concept - wrap up the values, then use bind to chain functions together.

The ?. operator mentioned in the article is simply some syntactic sugar for a monad, hence "monadic null checking".

On 12/11/13 2:14 AM, Walter Bright wrote:
> On 12/10/2013 3:53 PM, Ary Borenszweig wrote:
>> BTW, the other day I friend tried to explain me monads
>> and he realized couldn't understand them himself
>
> The best way to learn something is to try to explain it to someone else.

I don't know why the order of the words I wrote became like that. I meant to say:

"the other day a friend tried to explain me monads and he realized he couldn't understand them himself"

What you say is true: once you are able to explain something very well, you understand it much better.

On 12/11/13 11:32 AM, Robert Clipsham wrote:
> On Tuesday, 10 December 2013 at 23:53:25 UTC, Ary Borenszweig wrote:
>> On 12/10/13 5:35 PM, Namespace wrote:
>>> I love Monadic null checking. Would be great if D would have it.
>>
>> What does a monad have to do with that?
>>
>> (just out of curiosity... BTW, the other day I friend tried to explain
>> me monads and he realized couldn't understand them himself)
>
> Monads suffer from the same problem algebra, templates and many other
> things do in that they have a scary name and are often poorly explained.
>
> They way I like to think of monads is simply a box that performs
> computations. They have two methods, bind and return. return lets you
> put a value into the box, and bind lets you call some function with the
> value that's in the box. Probably the simplest example is the maybe
> monad ("monadic null checking"). The idea is to let you change something
> like this:
> ----
> auto a = ...;
> if (a != null) {
>      auto b = a.foo();
>      if (b != null) {
>          b.bar();
>          // And so on
>      }
> }
> ----
> Into:
> ----
> a.foo().bar();
> ----
>
> Here, the bind and return methods might look something like:
> ----
> // "return" function
> Maybe!Foo ret(Foo f) {
>      return just(f);
> }
> auto bind(Maybe!Foo thing, Foo function(Foo) fn) {
>      if(thing) {
>          return ret(fn(thing));
>      }
>      return nothing();
> }
> ----
> There are two functions here for getting instances of maybe - nothing
> and just. Nothing says "I don't have a value" and just says "I have a
> value". The bind method then simply says "if I have a value, call the
> function, otherwise just return nothing". The code above would be used
> as follows:
> ----
> bind(bind(a, &foo), &bar);
> ----
> With a bit of magic you can get rid of the overhead of function pointers
> and allow it to work with other function types, but it shows the general
> concept - wrap up the values, then use bind to chain functions together.
>
> The ?. operator mentioned in the article is simply some syntactic sugar
> for a monad, hence "monadic null checking".

Thanks for the explanation. I think I understand monads a bit more now. :-)

However, isn't it too much to call the "?." operator "monadic null checking"? I see it as just syntax sugar:

foo?.bar

is the same as:

(temp = foo) ? temp.bar : null

And so:

foo?.bar?.baz

it the same as:

(temp2 = ((temp = foo) ? temp.bar : null)) ? temp2.baz : null

By the way, in Crystal we currently have:

class Object
  def try
    yield
  end
end

class Nil
  def try(&block)
    nil
  end
end

You can use it like this:

foo.try &.bar
foo.try &.bar.try &.baz

Not the nicest thing, but it's implemented as a library solution. Then you could have syntactic sugar for that.

Again, I don't see why this is related to monads. Maybe because monads are boxes that can perform functions, anything which involves a transform can be related to a monad. :-P