I ran into this blog post today:  https://blogs.msdn.microsoft.com/dotnet/2017/11/15/nullable-reference-types-in-csharp/

It peeked my interested, because when I first started studying D, the lack of any warning or error for this trivial case surprised me.

// Example A
class Test
{
    int Value;
}

void main(string[] args)
{
    Test t;
    t.Value++;  // No compiler error, or warning.  Runtime error!
}
https://run.dlang.io/is/naTgHC

In C#, you get a compiler error.

// Example B
class Test
{
    public int Value;
}
					
public class Program
{
    public static void Main()
    {
        Test t;
        t.Value++;  // Error: Use of unassigned local variable 't'
    }
}
https://dotnetfiddle.net/8diEiG

But, it's not perfect:

// Example C
class Test
{
    private static Test _instance;
    public static Test Instance
    {
        get { return _instance; }
    }

    public int Value;
}
					
public class Program
{	
    public static void Main()
    {
        Test t = Test.Instance;
        t.Value++;  // No compiler error, or warning.  Runtime error!
    }
}
https://dotnetfiddle.net/GEv2fh

With Microsoft's proposed change, the compiler will emit a warning for Example C.  If you want to opt out of the warning, you'll need to declare `_instance` as `Test? _instance` (see the '?' there).

Notice that that is a "breaking" change for C#, but Microsoft still considers it an improvement to the language worth pursuing.  Is there hope for D, too?

Mike

On Friday, 17 November 2017 at 01:47:01 UTC, Michael V. Franklin wrote:
> // Example A
> class Test
> {
>     int Value;
> }
>
> void main(string[] args)
> {
>     Test t;
>     t.Value++;  // No compiler error, or warning.  Runtime error!
> }


//Test t;
Test t = new Test;

On Friday, 17 November 2017 at 01:47:01 UTC, Michael V. Franklin wrote:
>
> It peeked my interested, because when I first started studying D, the lack of any warning or error for this trivial case surprised me.
>
> // Example A
> class Test
> {
>     int Value;
> }
>
> void main(string[] args)
> {
>     Test t;
>     t.Value++;  // No compiler error, or warning.  Runtime error!
> }


Also, if you start with nothing, and add 1 to it, you still end up with nothing, cause you started with nothing. That makes completed sense to me. So why should that be invalid?

On Friday, 17 November 2017 at 01:47:01 UTC, Michael V. Franklin wrote:
> In C#, you get a compiler error.
>
> // Example B
> class Test
> {
>     public int Value;
> }
> 					
> public class Program
> {
>     public static void Main()
>     {
>         Test t;
>         t.Value++;  // Error: Use of unassigned local variable 't'
>     }
> }
> https://dotnetfiddle.net/8diEiG
>

Let's try reversing that question.

Is there hope for C#, so that it will let me do something with nothing.

D let's me do that ;-)

The problem though, seems to be the runtime environment..My code specifically said I wanted to do something with nothing, the compiler said, sure, go ahead..and then it crashed at execution?

Fix the runtime so it does what I want.

On Friday, 17 November 2017 at 02:25:21 UTC, codephantom wrote:
> On Friday, 17 November 2017 at 01:47:01 UTC, Michael V. Franklin wrote:
>>
>> It peeked my interested, because when I first started studying D, the lack of any warning or error for this trivial case surprised me.
>>
>> // Example A
>> class Test
>> {
>>     int Value;
>> }
>>
>> void main(string[] args)
>> {
>>     Test t;
>>     t.Value++;  // No compiler error, or warning.  Runtime error!
>> }
>
>
> Also, if you start with nothing, and add 1 to it, you still end up with nothing, cause you started with nothing. That makes completed sense to me. So why should that be invalid?

You are not ending with nothing, you are ending with a run time error in D. In C# it's a compile-time error. Ideally, something ending for sure in an error at run time, must be catch at compile-time.

On Friday, 17 November 2017 at 05:50:24 UTC, rumbu wrote:
> You are not ending with nothing, you are ending with a run time error in D. In C# it's a compile-time error. Ideally, something ending for sure in an error at run time, must be catch at compile-time.

Well.. sometimes it's just nice...to do nothing, and I'm glad D lets me do that.

And the runtime should just stay out of it. It's always interfering in something - even when its nothing.

On Friday, 17 November 2017 at 06:32:03 UTC, codephantom wrote:
> On Friday, 17 November 2017 at 05:50:24 UTC, rumbu wrote:
>> You are not ending with nothing, you are ending with a run time error in D. In C# it's a compile-time error. Ideally, something ending for sure in an error at run time, must be catch at compile-time.
>
> Well.. sometimes it's just nice...to do nothing, and I'm glad D lets me do that.
>
> And the runtime should just stay out of it. It's always interfering in something - even when its nothing.

I don't even imagine how the runtime can stay out of dereferencing a null pointer.

I know your aversion towards C#, but this not about C#, it's about safety. And safety is one of the D taglines.

On Friday, November 17, 2017 01:47:01 Michael V. Franklin via Digitalmars-d wrote:
> With Microsoft's proposed change, the compiler will emit a warning for Example C.  If you want to opt out of the warning, you'll need to declare `_instance` as `Test? _instance` (see the '?' there).

Personally, I'm flat out against anything that would generate a warning rather than an error. If the compiler can't guarantee that your code is wrong, then that check should be left up to a linter. As soon as something is a warning in the compiler, you're going to be forced to fix it whether it makes sense to fix it or not, because it's not appropriate to leave warnings in a project. Having a way to tell the compiler to shut up improves things, but it would be really annoying and is generally the sort of thing that would be left to a linter.

If we can add something to the compiler which finds bugs 100% correctly and generates an error for them, then I have no problem with that. But I don't want to see any warnings about things that "might" be wrong. I think that it was a huge mistake for Walter to add warnings to the compiler (which he only did after a lot of nagging, and I suspect that he agrees that it was a mistake; I'm sure that he's not entirely happy about it regardless). The compiler should only ever complain about something that is guaranteed to be wrong. Warnings are just errors in disguise but where what they're complaining about isn't necessarily bad code.

> Notice that that is a "breaking" change for C#, but Microsoft
> still considers it an improvement to the language worth pursuing.
>   Is there hope for D, too?

In general, Walter doesn't like stuff that requires code flow analysis. I believe that dmd does do _some_ code flow analysis, so I don't think that that's a deal breaker, but it's the sort of thing that I think tends to get shot down, because it gets complicated fast, and in general, D's solution to this problem was to default initialize everything to values that were either perfectly legitimate or as close as possible to error values so that the problem would be caught quickly (and is simpler than code flow analysis). If it can be implemented in a way that the compiler generates an error only when it's completely sure that what you're doing is wrong, then I see no problem with it, but it has to be an error, and the compiler can't be generating errors when what you're doing could actually be fine.

Personally, I'm inclined to think that not initializing a variable which defaults to null is a complete non-issue. Sure, it would be nice if the compiler caught it and told you so that you didn't have to even run your unit tests to find the problem (that's always nice), but it's also the sort of thing that's immediately obvious as soon as you hit that piece of code (which is very early on in the process if you're unit testing your code), and it doesn't even require writing additional unit tests to catch it - any tests that test the code properly will find the problem immediately. So, in practice, it's a mistake that's quickly found and fixed. As such, while I have no problem with the compiler giving an error when you've definitively screwed up and are calling a member function on a null object, I question that it actually fixes much, and I definitely don't want to be required to do something to my code to make the compiler shut up, because it's incorrectly decided that what I'm doing is wrong.

Another thing to consider with things like this though is generic code. It's pretty trivial to have generic code run afoul of anything warning that what you're doing might be wrong when it's actually just fine and pretty annoying to write in a way that makes the compiler shut up about it (a warning for unused variables would be a prime example where we'd have serious problems like that). At the moment, I can't think of why that would be a problem in this case (presuming that the compiler only complained when it definitively knew that the code was calling a member function on a null reference or pointer), but it's something that would have to be considered.

- Jonathan M Davis

On Friday, 17 November 2017 at 09:44:01 UTC, rumbu wrote:
>
> I know your aversion towards C#, but this not about C#, it's about safety. And safety is one of the D taglines.

Well the nice thing about that discussion (at: https://blogs.msdn.microsoft.com/dotnet/2017/11/15/nullable-reference-types-in-csharp/ ), was that not everyone agreed. So maybe there is hope for C# yet.

Indeed many C# users seemed to 'strongly' disagree, and good points were made for 'not' making the change.

Sounds to me, like too many people are writing incorrect code in the first place, and want to offload responsibility onto something other than themself. This is why we have bloated runtime checks these days.

I've always thought writing the correct code was the better option anyway.
Maybe even (god forbid)..  test it.

As for safety in D....it's already there.
.....

module test;

import std.stdio;

static immutable Exception TheYouIdiot_Exception = new Exception("You idiot!");

class Test
{
    int Value;
}

void main()
{
    Test t; //let assume this was intended. Otherwise the fault starts here.

    // ..

    if(!t)
        throw TheYouIdiot_Exception;  // problem solved.

    t.Value++;
}

On Friday, November 17, 2017 09:44:01 rumbu via Digitalmars-d wrote:
> I know your aversion towards C#, but this not about C#, it's about safety. And safety is one of the D taglines.

Completely aside from whether having the compile-time checks would be good or not, I would point out that this isn't actually a memory safety issue. If you dereference a null pointer or reference, your program will segfault. No memory is corrupted, and no memory that should not be accessed is accessed. If dereferencing a null pointer or reference in a program were a memory safety issue, then we'd either have to make it illegal to dereference references or pointers in @safe code or add additional runtime null checks beyond what already happens with segfaults, since aside from having non-nullable pointers/references, in the general case, we can't guarantee that a pointer or reference isn't null. At best, the compiler can detect it in certain instances (e.g. when a variable was initialized to null or assigned null, and it wasn't passed to anything else before it was used), but in most cases, it can't know.

So, this is purely about the compiler detecting a certain class of bug in programs and giving a warning or error when it does, not about memory safety.

- Jonathan M Davis