On 2/3/14, 10:22 PM, deadalnix wrote:
> On Tuesday, 4 February 2014 at 06:03:14 UTC, Andrei Alexandrescu wrote:
>> On 2/3/14, 9:09 PM, Jonathan M Davis wrote:
>>> I truly hope that that's never the case. Adding non-nullable
>>> references to the
>>> language is one thing; making them the default is quite another, and
>>> making
>>> them the default would break existing code. And given Walter's normal
>>> stance
>>> on code breakage, I'd be very surprised if he were in favor of making
>>> non-
>>> nullable references or pointers the default.
>>
>> We are considering making non-nullables the default, @nullable to mark
>> optionally null objects, and enable the related checks with an opt-in
>> compiler flag.
>>
>> Andrei
>
> That would be awesome. The breakage involved, is quite high however.

No breakage if the opt-in flag is not used.

Andrei

On Tuesday, 4 February 2014 at 06:03:14 UTC, Andrei Alexandrescu wrote:
> On 2/3/14, 9:09 PM, Jonathan M Davis wrote:
>> I truly hope that that's never the case. Adding non-nullable references to the
>> language is one thing; making them the default is quite another, and making
>> them the default would break existing code. And given Walter's normal stance
>> on code breakage, I'd be very surprised if he were in favor of making non-
>> nullable references or pointers the default.
>
> We are considering making non-nullables the default, @nullable to mark optionally null objects, and enable the related checks with an opt-in compiler flag.
>
> Andrei

I am really interested in learning more about how the data you have collected moved you and Walter to make this large change. Especially since it seems that much of the time arguments made for or against either side of the issue seem to be based on anecdotal evidence, or built up based on the small slice of coding that we each deal with. If you get time for an article that would be pretty cool.

Joseph

On Tuesday, 4 February 2014 at 06:49:57 UTC, Andrei Alexandrescu wrote:
>> That would be awesome. The breakage involved, is quite high however.
>
> No breakage if the opt-in flag is not used.
>
> Andrei

OK, If you are willing to do that change, I'm 200% behind !

Question, why do you propose to use @nullable instead of Nullable!T ?

On Tuesday, 4 February 2014 at 02:27:23 UTC, deadalnix wrote:
> On Tuesday, 4 February 2014 at 01:09:52 UTC, Meta wrote:
>> On Monday, 3 February 2014 at 23:34:59 UTC, deadalnix wrote:
>>> On Monday, 3 February 2014 at 22:23:52 UTC, Meta wrote:
>>>> If null is an invalid value to assign to a pointer, then there's no issue.
>>>>
>>>> int* foo()
>>>> {
>>>>  //Error: cannot implicitly convert typeof(null) to type int*
>>>>  return "/etc/foo".exists ? new int : null;
>>>> }
>>>
>>> Only cross abstraction boundaries is sufficient.
>>
>> Can you explain?
>
> void foo() {
>      Widget w = null; // OK
>      w.foo(); // Error w might be null.
>
>      w = new Widget();
>      w.foo(); // OK
>
>      if(condition) {
>          w = null;
>      }
>
>      w.foo(); // Error
>
>      if(w !is null) {
>          w.foo(); // OK
>      }
>
>      bar(w); // Error, w might be null=
>      return w; // Error, w might be null
> }

Why is `bar(w);` an error? I may be perfectly valid for `bar` to accept null as argument.

On Tuesday, 4 February 2014 at 13:11:49 UTC, Idan Arye wrote:
> Why is `bar(w);` an error? I may be perfectly valid for `bar` to accept null as argument.

It should declare its argument as Nullable!w then.

On Tuesday, 4 February 2014 at 13:20:12 UTC, Dicebot wrote:
> On Tuesday, 4 February 2014 at 13:11:49 UTC, Idan Arye wrote:
>> Why is `bar(w);` an error? I may be perfectly valid for `bar` to accept null as argument.
>
> It should declare its argument as Nullable!w then.

If non-null-by-default will be implemented that code will crash on the first line `Widget w = null;`. I was not talking about that - I was talking about the static analysis deadalnix demonstrated in the comments of that code.

On Tuesday, 4 February 2014 at 08:32:26 UTC, deadalnix wrote:
> On Tuesday, 4 February 2014 at 06:49:57 UTC, Andrei Alexandrescu wrote:
>>> That would be awesome. The breakage involved, is quite high however.
>>
>> No breakage if the opt-in flag is not used.
>>
>> Andrei
>
> OK, If you are willing to do that change, I'm 200% behind !
>
> Question, why do you propose to use @nullable instead of Nullable!T ?

Probably because `Nullable!` suggests that's it's a library solution - and it isn't. In order to implement nullables without core language support for nullables you need to do some workarounds that waste memory and cycles. Also, implementing it as a core language feature makes life easier for the optimizer.

At any rate, currently all built-in attributes that use the @ prefix(all two of them are declaration attributes - but `@nullable` should be a type attribute, so we can send things like `@nullable(int)` as template parameters.

On Tuesday, 4 February 2014 at 14:34:49 UTC, Idan Arye wrote:
> Probably because `Nullable!` suggests that's it's a library solution - and it isn't.

It should be. The way I'd do it is

Object o; // not null
@nullable Object o; // like we have today

BUT, user code would never use that. Instead, we'd have:

struct Nullable(T) if(__traits(compiles, (@nullable T) {}) {
   @nullable T;
}

// and a corresponding one so stuff like Nullable!int works


This gives us:

* Implementation help - no binary cost for Nullable!Object since it just uses null directly instead of a bool isNull field (the optimizer also knows this)

* Consistency with all other types. Nullable!int works, Nullable!Object can be passed to a template, inspected, etc. without new traits for isNullable and everything.

* Library functionality so we can also make other types that do the same kind of thing


Then, if we did the Type? syntax, it would just be rewritten into Nullable!Type. Nullable's definition would probably be in the auto-imported object.d so it always works.

On Tuesday, 4 February 2014 at 14:54:35 UTC, Adam D. Ruppe wrote:
> On Tuesday, 4 February 2014 at 14:34:49 UTC, Idan Arye wrote:
>> Probably because `Nullable!` suggests that's it's a library solution - and it isn't.
>
> It should be. The way I'd do it is
>
> Object o; // not null
> @nullable Object o; // like we have today
>
> BUT, user code would never use that. Instead, we'd have:
>
> struct Nullable(T) if(__traits(compiles, (@nullable T) {}) {
>    @nullable T;
> }
>
> // and a corresponding one so stuff like Nullable!int works
>
>
> This gives us:
>
> * Implementation help - no binary cost for Nullable!Object since it just uses null directly instead of a bool isNull field (the optimizer also knows this)
>
> * Consistency with all other types. Nullable!int works, Nullable!Object can be passed to a template, inspected, etc. without new traits for isNullable and everything.
>
> * Library functionality so we can also make other types that do the same kind of thing
>
>
> Then, if we did the Type? syntax, it would just be rewritten into Nullable!Type. Nullable's definition would probably be in the auto-imported object.d so it always works.

Sounds awesome.

On Tuesday, 4 February 2014 at 14:54:35 UTC, Adam D. Ruppe wrote:
> On Tuesday, 4 February 2014 at 14:34:49 UTC, Idan Arye wrote:
>> Probably because `Nullable!` suggests that's it's a library solution - and it isn't.
>
> It should be. The way I'd do it is
>
> Object o; // not null
> @nullable Object o; // like we have today
>
> BUT, user code would never use that. Instead, we'd have:
>
> struct Nullable(T) if(__traits(compiles, (@nullable T) {}) {
>    @nullable T;
> }
>
> // and a corresponding one so stuff like Nullable!int works
>
>
> This gives us:
>
> * Implementation help - no binary cost for Nullable!Object since it just uses null directly instead of a bool isNull field (the optimizer also knows this)
>
> * Consistency with all other types. Nullable!int works, Nullable!Object can be passed to a template, inspected, etc. without new traits for isNullable and everything.
>
> * Library functionality so we can also make other types that do the same kind of thing
>
>
> Then, if we did the Type? syntax, it would just be rewritten into Nullable!Type. Nullable's definition would probably be in the auto-imported object.d so it always works.

I'm interested in how this might fit in with your recent discovery in this thread:

http://forum.dlang.org/thread/majnjuhxdefjuqjlpbmv@forum.dlang.org?page=1