Zach the Mystic:

> Not disagreeing, but you had mentioned nullable types before, and I was wondering what they might look like also. Have you made an enhancement for these I could examine?

I opened this:
http://d.puremagic.com/issues/show_bug.cgi?id=4571

Part of the syntax is:

T? means T nullable
T@ = means not nullable.

But that ER is a confused mess, and in the meantime the @disable was introduced. Now the probability of such nullable syntax+semantics to be introduced in D is very low, so probably I will close down that ER.

Bye,
bearophile

On 4/6/13 4:10 AM, bearophile wrote:
> Zach the Mystic:
>
>> Not disagreeing, but you had mentioned nullable types before, and I
>> was wondering what they might look like also. Have you made an
>> enhancement for these I could examine?
>
> I opened this:
> http://d.puremagic.com/issues/show_bug.cgi?id=4571
>
> Part of the syntax is:
>
> T? means T nullable
> T@ = means not nullable.
>
> But that ER is a confused mess, and in the meantime the @disable was
> introduced. Now the probability of such nullable syntax+semantics to be
> introduced in D is very low, so probably I will close down that ER.
>
> Bye,
> bearophile

I think it's safe to close it. Nullable types have not enjoyed a lot of appreciation in C#.

Andrei

Andrei Alexandrescu:

> I think it's safe to close it. Nullable types have not enjoyed a lot of appreciation in C#.

On the other hand they have gained appreciation in almost every one of the other recent languages, as F#, Scala, Rust, and few Java-Like languages running on the JavaVM, so this is a not small failure point of D. I think all type-rich languages that will be designed in future will have nonnullable typing. D is  old-school on this.

Bye,
bearophile

On Saturday, 6 April 2013 at 12:41:46 UTC, Andrei Alexandrescu wrote:
> On 4/6/13 4:10 AM, bearophile wrote:
>> Zach the Mystic:
>>
>>> Not disagreeing, but you had mentioned nullable types before, and I
>>> was wondering what they might look like also. Have you made an
>>> enhancement for these I could examine?
>>
>> I opened this:
>> http://d.puremagic.com/issues/show_bug.cgi?id=4571
>>
>> Part of the syntax is:
>>
>> T? means T nullable
>> T@ = means not nullable.
>>
>> But that ER is a confused mess, and in the meantime the @disable was
>> introduced. Now the probability of such nullable syntax+semantics to be
>> introduced in D is very low, so probably I will close down that ER.
>>
>> Bye,
>> bearophile
>
> I think it's safe to close it. Nullable types have not enjoyed a lot of appreciation in C#.
>
> Andrei

In C#, all objects are already nullables, which make it not really useful.

In D, this is implementable as a lib anyway.

On Friday, 29 March 2013 at 08:58:06 UTC, kenji hara wrote:
> http://wiki.dlang.org/DIP32
>
> Kenji Hara

The {} syntax is already crowded, I don't think this is wise to use it here.

Timon already presented plenty of cases where it isn't as simple as presented in the DIP, and I can come up with a bunch of my own to add here. It don't think this is necessary as point have been made.

As a side note, I'd vote for deprecation of the {} syntax for structs to merge it with whatever is decided for tuples.

On Saturday, 6 April 2013 at 12:59:53 UTC, bearophile wrote:
> Andrei Alexandrescu:
>
>> I think it's safe to close it. Nullable types have not enjoyed a lot of appreciation in C#.
>
> On the other hand they have gained appreciation in almost every one of the other recent languages, as F#, Scala, Rust, and few Java-Like languages running on the JavaVM, so this is a not small failure point of D. I think all type-rich languages that will be designed in future will have nonnullable typing. D is  old-school on this.
>

Non nullable should be the default. Compiler know know how to track initialization.

On Saturday, 6 April 2013 at 08:10:30 UTC, bearophile wrote:
> Zach the Mystic:
>
>> Not disagreeing, but you had mentioned nullable types before, and I was wondering what they might look like also. Have you made an enhancement for these I could examine?
>
> I opened this:
> http://d.puremagic.com/issues/show_bug.cgi?id=4571
>
> Part of the syntax is:
>
> T? means T nullable
> T@ = means not nullable.
>
> But that ER is a confused mess, and in the meantime the @disable was introduced. Now the probability of such nullable syntax+semantics to be introduced in D is very low, so probably I will close down that ER.
>
> Bye,
> bearophile

Once dmd pull 1724 is merged, it would be possible to write:

class A {}

enum E : A
{
   e = new A
}

void main()
{
  E e; //a is allocated on heap
}

So, E type is some kind of nullable type (but this approach has drawbacks).

On Friday, 29 March 2013 at 08:58:06 UTC, kenji hara wrote:
> http://wiki.dlang.org/DIP32
>
> Kenji Hara

I'm not sure if this is off topic or redundant but couldn't many of these things be added to the standard library without a special syntax. for instance s function like unpack could allow

    import std.typecons;
    int a;
    char b ;
    unpack(a,b) = tuple(5, 'A');
    assert(a==5 && b=='A');

instead 0f

    (int a, char b) = (5,'A');

or whatever.

Would this help the problem?

On Wednesday, 13 August 2014 at 23:02:44 UTC, Philip Stuckey wrote:
> I'm not sure if this is off topic or redundant but couldn't many of these things be added to the standard library without a special syntax. for instance s function like unpack could allow
>
>     import std.typecons;
>     int a;
>     char b ;
>     unpack(a,b) = tuple(5, 'A');
>     assert(a==5 && b=='A');
>
> instead 0f
>
>     (int a, char b) = (5,'A');
>
> or whatever.
>
> Would this help the problem?

This is already possible with standard library but the fact that declarations need to be separate makes people not happy.

On Wednesday, 13 August 2014 at 23:26:29 UTC, Dicebot wrote:
> On Wednesday, 13 August 2014 at 23:02:44 UTC, Philip Stuckey wrote:
>> I'm not sure if this is off topic or redundant but couldn't many of these things be added to the standard library without a special syntax. for instance s function like unpack could allow
>>
>>    import std.typecons;
>>    int a;
>>    char b ;
>>    unpack(a,b) = tuple(5, 'A');
>>    assert(a==5 && b=='A');
>>
>> instead 0f
>>
>>    (int a, char b) = (5,'A');
>>
>> or whatever.
>>
>> Would this help the problem?
>
> This is already possible with standard library but the fact that declarations need to be separate makes people not happy.

Brings to mind C#'s new ability to declare locals within 'out' arguments.
if (int.TryParse("123", out int i)) { ...use 'i'... }