Which D features to emphasize for academic review article

Don Clugston dac at nospam.com
Tue Aug 14 07:04:45 PDT 2012


On 14/08/12 12:31, Mehrdad wrote:
> On Saturday, 11 August 2012 at 05:41:23 UTC, Walter Bright wrote:
>> On 8/10/2012 9:55 PM, F i L wrote:
>>> On the first condition, without an 'else z = ...', or if the
>>> condition was removed at a later time, then you'll get a compiler
>>> error and be forced to explicitly assign 'z' somewhere above using
>>> it. So C# and D work in "similar" ways in this respect except that C#
>>> catches these issues at compile-time, whereas in D you need to:
>>>   1. run the program
>>>   2. get bad result
>>>   3. hunt down bug
>>
>> However, and I've seen this happen, people will satisfy the compiler
>> complaint by initializing the variable to any old value (usually 0),
>> because that value will never get used. Later, after other things
>> change in the code, that value suddenly gets used, even though it may
>> be an incorrect value for the use.
>
>
> Note to Walter:
>
> You're obviously correct that you can make an arbitrarily complex
> program to make it too difficult for the compiler to enforce
> initialization, the way C# does (and gives up in some cases).
>
> What you seem to be missing is that the issue you're saying is correct
> in theory, but too much of a corner case in practice.
>
> C#/Java programmers ___rarely___ run into the sort of issue you're
> mentioning, and even when they do, they don't have nearly as much of a
> problem with fixing it as you seem to think.
>
> The only reason you run into this sort of problem (assuming you do, and
> it's not just a theoretical discussion) is that you're in the C/C++
> mindset, and using variables in the C/C++ fashion.
> If you were a "C#/Java Programmer" instead of a "C++ Programmer", you
> simply _wouldn't_ try to make things so complicated when coding, and you
> simply _wouldn't_ run into these problems the way you /think/ you would,
> as a C++ programmer.
>
>
> Regardless, it looks to me like you two are arguing for two orthogonal
> issues:
>
> F i L:  The compiler should detect uninitialized variables.
> Walter: The compiler should choose initialize variables with NaN.
>
>
> What I'm failing to understand is, why can't we have both?
>
> 1. Compiler _warns_ about "uninitialized variables" (or scalars, at
> least) the same way C# and Java do, __unless__ the user takes the
> address of the variable, in which case the compiler gives up trying to
> detect the flow (like C#).
> Bonus points: Try to detect a couple of common cases (e.g. if/else)
> instead of giving up so easily.
>
> 2. In any case, the compiler initializes the variable with whatever
> default value Walter deems useful.
>
>
> Then you get the best of both worlds:
>
> 1. You force the programmer to manually initialize the variable in most
> cases, forcing him to think about the default value. It's almost no
> trouble for
>
> 2. In the cases where it's not possible, the language helps the
> programmer catch bugs.
>
>
> Why the heck D avoids #1, I have no idea.

DMD detects uninitialized variables if you compile with -O. It's hard to 
implement the full Monty at the moment, because all that code is in the 
backend rather than the front-end.

> It's one of the _major_ features of C# and Java that help promote
> correctness, and #1 looks orthogonal to #2 to me.

Completely agree.
I always thought the intention was that assigning to NaN was simply a 
way of catching the difficult cases that slip through compile-time 
checks. Which includes the situation where the compile-time checking 
isn't yet implemented at all.
This is the first time I've heard the suggestion that it might never be 
implemented.

The thing which is really bizarre though, is float.init. I don't know 
what the semantics of it are.


More information about the Digitalmars-d mailing list