Michel Fortin wrote:
> unittest {
>     NonNullable!Object o;

Here o is null.

>     NonNullable!ClassInfo o2 = o.classinfo;
>     NonNullable!TypeInfo o3;
>     //NonNullable!Object o4 = o2; // FIXME: polymorphic NonNullable
>     o = new Object;
>     o = o2;
>     try {
>         o = o3; // should throw
>         o.toString();
>         assert(0, "prior assignment should have thrown");
>     } catch (IllegalNullAssignment e) {
>         // ok, error thrown.
>     }
> }

Ary Borenszweig wrote:
> Michel Fortin wrote:
>> unittest {
>>     NonNullable!Object o;
> 
> Here o is null.

Sorry, just read the class comments. But if this can't be implemented without compiler support... then it's not of much use. :-(

On 2010-02-10 22:54:40 -0500, Ary Borenszweig <ary@esperanto.org.ar> said:

> Ary Borenszweig wrote:
>> Michel Fortin wrote:
>>> unittest {
>>>     NonNullable!Object o;
>> 
>> Here o is null.
> 
> Sorry, just read the class comments. But if this can't be implemented without compiler support... then it's not of much use. :-(

To recapitulate the documentation comment at the top of NonNullable: it is indeed null until the first assignment. It's non nullable in the sense that you can't make it null, but it still can be null if you assign nothing to it. It means that if you encounter a null value in a non-nullable you know it was never initialized. So the obvious place to look is where it should have been initialized. I really wonder how bad this would be in practice (I haven't used it much yet).

Unfortunately, there isn't a better way to implement NonNullable at the moment. An option could be to throw immediately at construction, but constructors with no arguments are not available for structs, and I'm not sure it'd be so great anyway.

There is also the issue of lack of polymorphism: a NonNullable!MyObject variable won't implicitly convert to NonNullable!Object, although I've been able to make it work for non-construction assignments using a template opAssign.

So I agree with you that it's of limited utility. I think it can still be useful at times. What would be great is non-nullable by default, but that's another thing entirely.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

"bearophile" <bearophileHUGS@lycos.com> wrote in message news:hkv7u7$1a31$1@digitalmars.com...
> Walter Bright:
>
> [about non-nullable types]
>> It's a benefit/cost issue. There are no bug-preventing features that are without cost, the idea is to maximize the ratio.
>
> It surely has a cost (you can see it in the Cyclone language: it's safe but quite fussy, so the costs for the programmer can be high enough to discourage its use), but I have not tried this feature in other languages, so it's not easy for me to measure its costs :-)
>

I was assuming he meant cost of implementing that feature, but maybe you're right...?

Nick Sabalausky wrote:
> I was assuming he meant cost of implementing that feature, but maybe you're right...? 

I meant the cost to the user.

Wed, 10 Feb 2010 23:11:54 -0800, Walter Bright wrote:

> Nick Sabalausky wrote:
>> I was assuming he meant cost of implementing that feature, but maybe you're right...?
> 
> I meant the cost to the user.

The fact is that some of the references in a correct program are non- nullable. If the program behaves according to the spec, those references will never point to null. What a language designer should do is to analyze the use cases and make the more common case the default. Type inference could aid the user here. I'm not sure how much trouble wrong guesses would cause, though.

Ary Borenszweig:

>But if this can't be implemented without compiler support... then it's not of much use. :-(<

There's another solution: to make D2/D3 itself flexible enough that you can implement your own simple "extensions" to the type system, so you can actually implement not-nullable references by default. This isn't impossible (there are many papers about this, it can be done in Scheme, etc).

Once such flexibility is present, you can quickly create such plug-ins to the type system. Like in Firefox, plug-ins are a very good way to experiment new features, that can be later added to the main software if they are good. (Recently GCC has gained the ability to be use plug-ins, but here I am talking about something in the language, not in the compiler).

Related: I think the downsides of something like the AST macros (that is community fragmentation, etc) can be quite mitigated if the main purpose of them is to allow to create experimental features that later can be refused or accepted into the official language :-)

Bye,
bearophile

> There's another solution: to make D2/D3 itself flexible enough that you can implement your own simple "extensions" to the type system, so you
>can actually implement not-nullable references by default. This isn't impossible (there are many papers about this,
>it can be done in Scheme, etc).

"everything is possible with code" - its not the question of how to start an plugin/dll based function from descent compiler steps... thats too easy to even talk about

but how should the plugin-system work?
what compiler-functions should be changeable through plugins?
how do the different engine like parser, semantic analyser etc work together with the plugin, etc.? that is the nearly impossible to answer question - what do the LLVM-guys think about plugin like that

and firefox-plugins are far too easy in its possible feature-set compared to what is needed to add an type to an compiler

Michel Fortin wrote:
> On 2010-02-10 22:54:40 -0500, Ary Borenszweig <ary@esperanto.org.ar> said:
> 
>> Ary Borenszweig wrote:
>>> Michel Fortin wrote:
>>>> unittest {
>>>>     NonNullable!Object o;
>>>
>>> Here o is null.
>>
>> Sorry, just read the class comments. But if this can't be implemented without compiler support... then it's not of much use. :-(
> 
> To recapitulate the documentation comment at the top of NonNullable: it is indeed null until the first assignment. It's non nullable in the sense that you can't make it null, but it still can be null if you assign nothing to it. It means that if you encounter a null value in a non-nullable you know it was never initialized. So the obvious place to look is where it should have been initialized. I really wonder how bad this would be in practice (I haven't used it much yet).

That makes sense. :)

> Unfortunately, there isn't a better way to implement NonNullable at the moment. An option could be to throw immediately at construction, but constructors with no arguments are not available for structs, and I'm not sure it'd be so great anyway.

Maybe in D2 you will be able to put @disable to the default constructor of the struct, so you'll have to explicity assign something to it.

> There is also the issue of lack of polymorphism: a NonNullable!MyObject variable won't implicitly convert to NonNullable!Object, although I've been able to make it work for non-construction assignments using a template opAssign.
> 
> So I agree with you that it's of limited utility. I think it can still be useful at times. What would be great is non-nullable by default, but that's another thing entirely.

Yes, I think non-nullable by default is better.

Walter Bright, el 10 de febrero a las 14:28 me escribiste:
> Leandro Lucarella wrote:
> >This supposedly "safe" program under Mac OS X 10.6 doesn't give any error neither at compile time nor at runtime, yet it isn't memory-safe at all as it corrupts some part of the memory space.
> 
> @safe is in its infancy, and I expect there to be some gaps. We'll get them plugged over time. In the meantime, it's great that you filed a bug report on it.

It wasn't me, but kudos for the reporter indeed =)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------