On Monday, 17 September 2012 at 13:43:21 UTC, Russel Winder wrote:
> Somewhat hypocritically as I cannot volunteer myself just now… just
> because Walter didn't get round to it, doesn't mean it can't be done.
> People who want the feature should find a way of creating the resource
> to make it happen. Four ways: volunteer to do the work themselves; club
> together to raise the cash to contract someone to do the work; get an
> organization to stump up a person to do the work; get an organization or
> seven to stump up cash to contract someone to do the work. There is
> nothing quite like providing a pull request to get things moving ;-)

!

On 9/17/12 10:28 AM, Alex Rønne Petersen wrote:
> On 17-09-2012 15:12, Andrei Alexandrescu wrote:
>> On 9/17/12 6:52 AM, deadalnix wrote:
>>>> Regardless, the solution at this point is going to be to add
>>>> std.typecons.NonNullable. It would be in there already, but the pull
>>>> request
>>>> with it needed more work, and it hasn't been resubmitted yet.
>>>>
>>>
>>> I don't think this is implementable as a lib in a satisfying way.
>>
>> It is, but it needs just a bit of language support in constructors.
>> Walter never got around to it.
>>
>> Andrei
>
> What support, exactly?
>
> I mean, we have @disable already.

Minimal control flow inside constructors. It needs to ensure that all NonNull member variables get initialized.

Andrei

On 9/17/12 9:43 AM, Russel Winder wrote:
> Somewhat hypocritically as I cannot volunteer myself just now… just
> because Walter didn't get round to it, doesn't mean it can't be done.
> People who want the feature should find a way of creating the resource
> to make it happen. Four ways: volunteer to do the work themselves; club
> together to raise the cash to contract someone to do the work; get an
> organization to stump up a person to do the work; get an organization or
> seven to stump up cash to contract someone to do the work. There is
> nothing quite like providing a pull request to get things moving ;-)

Yah indeed. We should improve and systematize the use of DIPs. A DIP should have specific states such as "RFC", "For review", "Accepted", "Implementing", and "Implemented".

The acceptance of a DIP means that an implementation of it will be merged without objections (save, of course, for implementation-related ones).

Committing to such a process ensures that features are specified in good level of detail and would encourage people to work on things in understanding that their work will bear fruit.


Andrei

Le 17/09/2012 15:12, Andrei Alexandrescu a écrit :
> On 9/17/12 6:52 AM, deadalnix wrote:
>>> Regardless, the solution at this point is going to be to add
>>> std.typecons.NonNullable. It would be in there already, but the pull
>>> request
>>> with it needed more work, and it hasn't been resubmitted yet.
>>>
>>
>> I don't think this is implementable as a lib in a satisfying way.
>
> It is, but it needs just a bit of language support in constructors.
> Walter never got around to it.
>
> Andrei

So it isn't. That was my point. You need the compiler to help you on that one.

On 9/17/12 12:41 PM, deadalnix wrote:
> Le 17/09/2012 15:12, Andrei Alexandrescu a écrit :
>> On 9/17/12 6:52 AM, deadalnix wrote:
>>>> Regardless, the solution at this point is going to be to add
>>>> std.typecons.NonNullable. It would be in there already, but the pull
>>>> request
>>>> with it needed more work, and it hasn't been resubmitted yet.
>>>>
>>>
>>> I don't think this is implementable as a lib in a satisfying way.
>>
>> It is, but it needs just a bit of language support in constructors.
>> Walter never got around to it.
>>
>> Andrei
>
> So it isn't. That was my point. You need the compiler to help you on
> that one.

I don't think that was your point. My understanding is that your point was that (a) with or without @disable, one cannot implement NonNull pointers in the library, and (b) there is need for _specific_ support for NonNull in the language. Our position is that NonNull is only one of several instances of a much more general pattern, which can be addressed with @disable once it is properly tracked inside constructors.


Andrei

Andrei Alexandrescu:

> Our position is that NonNull is only one of several instances of a much more general pattern, which can be addressed with @disable once it is properly tracked inside constructors.

It's an iterative process: some people invent a feature and put in a language, others find it partially implementable in libraries and/or useful if generalized. Later someone maybe finds that one of the library constructs is so commonly used that adding some built-in sugar (like a trailing @) makes code shorter and nicer, and so on and on :-)

Bye,
bearophile

On 9/17/12 1:15 PM, bearophile wrote:
> Andrei Alexandrescu:
>
>> Our position is that NonNull is only one of several instances of a
>> much more general pattern, which can be addressed with @disable once
>> it is properly tracked inside constructors.
>
> It's an iterative process: some people invent a feature and put in a
> language, others find it partially implementable in libraries and/or
> useful if generalized. Later someone maybe finds that one of the library
> constructs is so commonly used that adding some built-in sugar (like a
> trailing @) makes code shorter and nicer, and so on and on :-)
>
> Bye,
> bearophile

That sounds nice but it turns out it's not the way @disable came about.

Andrei

Le 17/09/2012 13:07, Jonathan M Davis a écrit :
> On Monday, September 17, 2012 13:00:15 deadalnix wrote:
>> Don't take this wrong, I do know that this is a major breakage, and
>> would arm the language if applied in any short term manner. Still,
>> acknowledging error that have been made is usefull.
>
> Not everyone agrees that an error _was_ made. There's a big difference between
> acknoweldging that non-nullable references could be useful and agreeing that
> having nullable references be the default was a bad idea. I very much that it
> will _ever_ happen that non-nullable references would be the default
> (certainly, it will _not_ happen in D2), even if they were added.
>
> - Jonathan M Davis

Having written a lot of Java code and reviewed even more, I can assure you that code written correctly in regard of null is the exception rather than the rule.

Plus, all null checks tends to add a runtime cost, and most reference will never be null anyway (expect in case of an attack, an invalid use of an API, unexpected situation, etc . . .).

The cases where you really want null to be a valid value are the exception rather than the rule. And most of the code is written like if references couldn't be null.

I saw many Java software explode because of NullPointerException, and it was sometime really hard to debug (when race condition get into play for instance, as I did in Apache Cayenne).

D have already made a step in a direction similar to non nullable references with other types initialization. float initialize to NaN and char to invalid codepoints. In other terms poison values. It is useful, because it avoid to implement the control flow required to ensure that a variable is initialized, but not what you are advocating here (you don't seem to consider null as a poison value).

To implement non nullable, whatever the way, such control flow must be implemented. And it put the question of default initializer back on the table as it open for more advanced way of handling the problem.

Le 17/09/2012 19:07, Andrei Alexandrescu a écrit :
> On 9/17/12 12:41 PM, deadalnix wrote:
>> Le 17/09/2012 15:12, Andrei Alexandrescu a écrit :
>>> On 9/17/12 6:52 AM, deadalnix wrote:
>>>>> Regardless, the solution at this point is going to be to add
>>>>> std.typecons.NonNullable. It would be in there already, but the pull
>>>>> request
>>>>> with it needed more work, and it hasn't been resubmitted yet.
>>>>>
>>>>
>>>> I don't think this is implementable as a lib in a satisfying way.
>>>
>>> It is, but it needs just a bit of language support in constructors.
>>> Walter never got around to it.
>>>
>>> Andrei
>>
>> So it isn't. That was my point. You need the compiler to help you on
>> that one.
>
> I don't think that was your point. My understanding is that your point
> was that (a) with or without @disable, one cannot implement NonNull
> pointers in the library, and (b) there is need for _specific_ support
> for NonNull in the language. Our position is that NonNull is only one of
> several instances of a much more general pattern, which can be addressed
> with @disable once it is properly tracked inside constructors.
>
>
> Andrei

Quoting myself : « I don't think this is implementable as a lib in a satisfying way. » (assuming, in the current state of things)

I made other point in other posts, but in that one, I just say that non nullable references require compiler support in some way compared to what we have now.

This support can be reserved to non null, or can be a larger problem (like @disable as you mention) that allow to solve the non null problem. I don't see how what I write limit things on that topic.

On Saturday, 15 September 2012 at 23:28:36 UTC, Walter Bright wrote:
> I wouldn't worry about it. I suspect that most C++ programmers think that references cannot be null.


Yeah, they can't be null _legally_.

Kind of like how in D you can't strip away const _legally_.

But the compiler doesn't complain if you don't obey the rules.