www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: null [re: spec#]

reply bearophile <bearophileHUGS lycos.com> writes:
Nick Sabalausky:

 You can label C#-style init-checking "wishy-washy" all you want, but that's 
 still a hell of a lot better than "wrong", which is what D does (as 
 evidenced by my first example above).

I think all you have written in this post is correct. In this regard D is better than C and C# is better than D. So the question becomes if D is "good enough" here. A language "works" or fail for the whole ecosystem of its features. This means that even if a language has a less safe feature, other parts of the language may be able to compensate for it. This means that even if D default initialization may lead to some troubles, some other features may be enough to cover and avoid those problems. Well implemented nonnull types may be one of such patching features. But keep in mind that it's not easy to implement well nonnull types in an OOP language. They do have some corner cases (collection initialization is just one of them), that must be faced. The good thing is that other people have already found such corner cases and have invented "good" solution for them, so it's a matter of understanding them and then implementing it. In this thread I have seen discussed only about 1/3 of the corner cases and troubles needed to implement nonull types well enough. This paper contains the solution of about 1/4 of the problems, that may require a notDelayed attribute (the other problems are collection initialization and simplified typestate management): http://research.microsoft.com/apps/pubs/default.aspx?id=67979 Also, keep in mind that while default initialization of variables was adopted in D to avoid flow analysis, if you want to implement nonnull types "well enough" you need a simplified form of flow analysis again. I have explained why both in my bug report and in some answers in this thread. If there is some vague interest in adding nonnull types to D3, then this discussion has to become much less noisy and more focused on how to solve those "corner cases" (answer: probably copying the solutions already invented). Bye, bearophile
Nov 07 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:ib6fuj$3j6$1 digitalmars.com...
 This paper contains the solution of about 1/4 of the problems, that may 
 require a  notDelayed attribute (the other problems are collection 
 initialization and simplified typestate management):
 http://research.microsoft.com/apps/pubs/default.aspx?id=67979

I only read the overview on that page, but it sounds like that could just be handled with ML-style nullable ("Option") types like foobar and I have suggested. Am I missing something? (I guess maybe I should just read the PDF :) ) Also, I'm curious what you mean by "collection initialization" and "simplified typestate management".
Nov 07 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Nick Sabalausky:

 Also, I'm curious what you mean by "collection initialization" and 
 "simplified typestate management".

Collections, like an array, need a temporary transient state where they may contain nulls too. The simple typestate management means that if you want to implement nonnull types well, the type system need to see the type of a variable as nullable in a point of the code, and nonnull later. The presence of an if statement or assert or cast needs to change the state of the type of the variable. I have explained a bit both things several times in posts. The problem with collections and the typestate needs are explained in the original little tutorial about Spec# in my first post of this thread. Bye, bearophile
Nov 07 2010