November 08, 2010
> This way or another, you need a null check. Why extra syntax?

This is also how it is done in those languages no?
They also have null checks at every assignment, but since compiler puts those lines, you don't know anything.

Maybe this is not what you mean?

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
November 08, 2010
so Wrote:

> > This way or another, you need a null check. Why extra syntax?
> 
> This is also how it is done in those languages no?
> They also have null checks at every assignment, but since compiler puts
> those lines, you don't know anything.
> 
> Maybe this is not what you mean?

Do you care about performance? If you zealously design with non-nulls, you won't have too many checks.
November 08, 2010
On Sunday, November 07, 2010 18:42:08 Adam Burton wrote:
> 1. Default struct constructor.
> This means the NN can be created without assigning a value. I have tried to
> get around this issue somewhat by adding a null check in the invariant but
> it seems the invariant is not called when using the default constructor.
> Should it be or should it not? If it is then atleast while contracts are
> enabled we get to know about uninitialised NNs.

There are no default constructors for structs. They use init, which is known at compile-time, so there is no constructor for the invariant to be called after. It's quite easy to create structs which pass their invariant when you construct them with a constructor but whose init fails the invariant. The fact that the invariant gets called before opAssign() doesn't help either: http://d.puremagic.com/issues/show_bug.cgi?id=5058

The result is that at this point, you pretty much either need to have init pass your invariant or have no invariant.

- Jonathan M Davis
November 08, 2010
Kagamin wrote:

> Adam Burton Wrote:
> 
>> The above seems correct to me. You are assigning a nullable to a non- nullable so you force the user to assess that is correct and provide an override. Based on that I've had a crack at this myself.
> 
> This becomes not just an annotation, but another type. When you pass argument by ref, you don't have to convert it to ref, you just pass it.
Yes, the fact it is a different type is an implementation detail of my attempt to also get a basic NN compile-time check.
> 
>> NN!Super without a null check, you only check for nulls when crossing from the nullable world to non-nullable using toNN. It also means code like below is not possible without explicitly saying I want to cross from nullable to non-nullable (using toNN) which offers some sort of compile time check (not as good as a compiler checking for "if is null" but it is something).
>> 
>> A a = null;
>> NN!A b = a;	// will not compile
>> NN!A b = toNN(a);	// inserts the null runtime check
>> NN!A c = b; // No null check as there is no need.
> 
> This way or another, you need a null check. Why extra syntax?
To get informed by the compiler I am crossing into NN code that I did not explicitly authorise. I thought that is a key part of the NN feature request. Granted with a template I can't get it inspecting the code around it for null checks but by making the cross from null to NN explicit it can help people potentially catch code where they've maybe not fully assessed the impact of the potential null floating around their code.

November 08, 2010
On 11/7/10 11:34 PM, spir wrote:
> On Sun, 07 Nov 2010 19:12:02 -0600
> Andrei Alexandrescu<SeeWebsiteForEmail@erdani.org>  wrote:
>
>> On 11/7/10 1:54 PM, retard wrote:
>>> Sun, 07 Nov 2010 19:39:09 +0200, so wrote:
>>>
>>>>> Andrei's stance is, either a library addon or ship D without that
>>>>> feature. D's library already contains both tuples and algebraic data
>>>>> types. They're simple to use, almost like in Python. The reason for
>>>>> library addons isn't that builtin features make less sense, the reason
>>>>> is that TDPL is already out and we can't improve the language in any
>>>>> radical way.
>>>>
>>>> Lets talk about solution in this thread more than politics, politics
>>>> "never" improve anything.
>>>
>>> There was this other thread here -- "why a part of d community do not
>>> want to go to d2?"
>>>
>>> One reason is, there's no good process for handling these feature
>>> proposals. Walter attends useless bikeshed discussions and spreads
>>> misinformation about things he doesn't get, Andrei has excellent
>>> knowledge of languages but he often prefers staying in the background.
>>>
>>> There are these DIPs in wiki4d. Were they useful? At least it seems that
>>> this thread is leading nowhere. Half of the people don't know what non-
>>> nullable means.
>>
>> In all honesty, the distribution of those who don't understand non-null
>> is about equal across the proponents and the opponents :o).
>
> Perhaps a great help would be to approach it so-to-say backwards: option types à la Haskell
> http://en.wikipedia.org/wiki/Option_type

That would be Algebraic.

> (The fact that our pointers are nullable by default makes it difficult to imagine the opposited pov, I guess.)

Agreed.


Andrei
1 2 3
Next ›   Last »