On Tuesday, 20 November 2018 at 00:30:44 UTC, Jordi Gutiérrez Hermoso wrote:
> On Monday, 19 November 2018 at 21:57:11 UTC, Neia Neutuladh wrote:
>
>> [...]
>
> What do you think about making the syntax slightly more explicit and warn or possibly error out if you don't do it that way? Either
>
>   SomeClass c = null;
>
> or
>
>   SomeClass c = new SomeClass();
>
> and nothing else.
>
>> [...]
>
> Nulls/Nones are always a big gap in a language's type system. A common alternative is to have some Option/Maybe type like Rust or Haskell or D's Variant. How about making that required to plug the null gap?

You can give optional (https://code.dlang.org/packages/optional) a try and see if that works for you.

On Tuesday, 20 November 2018 at 03:24:56 UTC, Neia Neutuladh wrote:
> On Tue, 20 Nov 2018 00:30:44 +0000, Jordi Gutiérrez Hermoso wrote:
>> On Monday, 19 November 2018 at 21:57:11 UTC, Neia Neutuladh wrote:
>> 
>>> Programmers coming from nearly any language other than C++ would find it expected and intuitive that declaring a class instance variable leaves it null.
>> 
>> What do you think about making the syntax slightly more explicit and warn or possibly error out if you don't do it that way?
>
> The prevailing idea is that warnings are either non-problems, in which case they shouldn't be emitted, or things you really need to fix, in which case they should be errors.
>
> Things that are sometimes errors can be left to lint tools.
>
>> Either
>> 
>>    SomeClass c = null;
>> 
>> or
>> 
>>    SomeClass c = new SomeClass();
>> 
>> and nothing else.
>
> That would work, though it would be mildly tedious.
>
> However, the general philosophy with D is that things should be implicitly initialized to a default state equal to the `.init` property of the type. That default state can be user-defined with structs, but with other types, it is generally an 'empty' state that has well-defined semantics. For floating point values, that is NaN. For integers, it's 0. For arrays, it's a null array with length 0. For objects and pointers, it's null.
>
>> Nulls/Nones are always a big gap in a language's type system. A common alternative is to have some Option/Maybe type like Rust or Haskell or D's Variant.
>
> Variant is about storing arbitrary values in the same variable. Nullable is the D2 equivalent of Option or Maybe.
>
>> How about making that required to plug the null gap?
>
> That's extremely unlikely to make it into D2 and rather unlikely to make it into a putative D3. However, if you feel strongly enough about it, you can write a DIP.
>
> I've used Kotlin with its null safety, and I honestly haven't seen benefits from it. I have seen some NullPointerExceptions in slightly different places and some NullPointerExceptions instead of empty strings in log messages, but that's it.

Think this would highly depend on your usecase. Having crashing mobile apps mostly leads to bad reviews because it's a UX nightmare for e.g. And with webservices it's a pain a lot of the times when it just crashes as well (analytics workers for e.g.).

Kotlin's null safety stops you from this quite well as long as you don't interface with java libraries - then it's near useless because your compiler guarantees go out the window. But Swift... so far  ... 👌

It's also a code review blessing. You just know for sure that this code won't crash and the object is "valid" because they've properly unwrapped a nullable. I can't even count the number of times (and I'd wager there're millions of similar commits) where I've put up a commit (during my c++ days) that says "fix crash" and the code is just "if(!ptr) { return; }" or a variant of that.

Ok, sorry, I rambled a bit :p

Cheers,
- Ali

On Monday, 19 November 2018 at 21:39:22 UTC, Adam D. Ruppe wrote:
> On Monday, 19 November 2018 at 21:23:31 UTC, Jordi Gutiérrez Hermoso wrote:
>> What's the reasoning for allowing this?
>
> The mistake is immediately obvious when you run the program, so I just don't see it as a big deal. You lose a matter of seconds, realize the mistake, and fix it.
>
> What is your proposal for handling it? The ones usually put around are kinda a pain to use.

Does D have a linter which warns about certain style of coding like this?

On Monday, 19 November 2018 at 21:39:22 UTC, Adam D. Ruppe wrote:
> On Monday, 19 November 2018 at 21:23:31 UTC, Jordi Gutiérrez Hermoso wrote:
>> What's the reasoning for allowing this?
>
> The mistake is immediately obvious when you run the program, so I just don't see it as a big deal. You lose a matter of seconds, realize the mistake, and fix it.

This only applies to little scripts and unittests maybe.

Not when you're writing any kind of relatively larger application that involves being run for longer or if there's more possible permutations of your state variables.

On Monday, 19 November 2018 at 21:23:31 UTC, Jordi Gutiérrez Hermoso wrote:
> Why does nobody seem to think that `null` is a serious problem in D?

Because the more you learn about D the less you want to use classes. I view class as compatibility feature when you want to port Java code to D. For regular code just use structs. For inheritance you could use alias, for polymorphism - templates etc. If you want to write OOP code you dont have to always start with keyword class.

And since you dont use classes you dont view null as a high priority problem.

On Tuesday, 20 November 2018 at 11:11:43 UTC, aliak wrote:
> This only applies to little scripts and unittests maybe.
>
> Not when you're writing any kind of relatively larger application that involves being run for longer or if there's more possible permutations of your state variables.

Umm... if you write a larger application not knowing what is a reference type, you're into lots and lots of problems.

On Monday, 19 November 2018 at 21:23:31 UTC, Jordi Gutiérrez Hermoso wrote:
> When I was first playing with D, I managed to create a segfault by doing `SomeClass c;` and then trying do something with the object I thought I had default-created, by analogy with C++ syntax.

D is more similar to Java here and works like languages with reference types - Java, C#, Python, Ruby, JavaScript. Also AFAIK in C++ objects are garbage-created by default, so you would have a similar problem there. To diagnose crashes on linux you can run your program under gdb.

On Tuesday, 20 November 2018 at 09:27:03 UTC, aberba wrote:
> Does D have a linter which warns about certain style of coding like this?

AFAIK, dscanner does some linting.

On Tuesday, 20 November 2018 at 09:27:03 UTC, aberba wrote:
> Does D have a linter which warns about certain style of coding like this?

dscanner might check it. I don't know though.

On Tuesday, 20 November 2018 at 13:27:28 UTC, welkam wrote:
> Because the more you learn about D the less you want to use classes.

classes rock. You just initialize it. You're supposed to initialize *everything* anyway.