On Mon, 28 Feb 2005 23:15:21 -0500, Ben Hinkle wrote:

> "Derek Parnell" <derek@psych.ward> wrote in message news:1myhii2vp4h97$.5zhponxkjp52$.dlg@40tude.net...
>> On Tue, 1 Mar 2005 14:39:18 +1100, Matthew wrote:
>>
>>
>> [snipped a lot of good stuff that I might come back to]
>>
>>> Does no one else get this?!?!
>>
>> I must admit that if I really look at what has been said so far, I feel a
>> little offended by Walter's apparent attitude. It's sort of like Walter
>> assumes I still wear nappies (diapers) and can't be trusted to use a
>> toilet
>> correctly. I guess that's the crux as I see it now; Walter doesn't trust
>> me; its not personal, as he doesn't trust any programmer.
> 
> I get the opposite impression - the situation he's arguing for is allow implicit casting without any warnings. That's putting all the responsibility on the coder (or other tools besides the compiler) to make sure it's right.

But why no warnings? Because he doesn't trust us to handle the situation responsibly? However, I'm resigned to wait for a 'lint' to appear.

>> If I could be trusted to write responsible code, then DMD would be free to
>> show me what could possibly be mistakes that I've made, and then let me
>> act
>> on them in a responsible manner, or at least take responsibility for my
>> coding.
> 
> I expect the grumbling masses will eventually make Walter put a warning or two in the "verbose mode".

I wouldn't hold my breath.

>> It could be that Walter has seen so much irresponsible code that he
>> assumes
>> everybody (including himself?) will always do the wrong thing if they
>> could. And that position hurts a little, so maybe I'm too much of a boy
>> scout.
> 
> He's not a backseat driver - he's letting us drive on our own without someone nagging them to signal when changing lanes, etc.
> 

I'm sorry Ben, I guess I didn't make myself clear again ;-)

*I* want to control the nagging, not let someone else decide for me whether I should be nagged or not.

-- 
Derek
Melbourne, Australia
1/03/2005 3:17:45 PM

On Tue, 1 Mar 2005 15:17:12 +1100, Matthew <admin@stlsoft.dot.dot.dot.dot.org> wrote:
> "Regan Heath" <regan@netwin.co.nz> wrote in message
> news:opsmxxnciy23k2f5@ally...
>> Sure, but how do you pick the right thing in this case? without
>> canvasing  every programmer in existance?
>
> That's my point. The only person is the programmer writing the code
> that's about to be compiled. Any other judgement is flawed.

Fair enough. So, the tool, whatever it is, must be very configurable, in order to make the right choice for each person it is used by, right?

I think, and this is due to Walter convincing me some time back, that the compiler should behave the same no matter which platform you compile your code on, code should not pass one compiler and fail another.

There seems to me to be only one path to achieve this, and that is to define everything that is an error, and not allow anything outside that to be given as an error or a warning.

The reason you cannot go on to define all the possible warnings, is that, as you've shown there are many of them, and each person has different ideas about what should be warned about.

Given that, and the desire for the compiler to behave the same in all incarnations, warnings are not allowed.

I think there are several cases, of which this is one, where it's not likely enough to always be an error, or isn't detectable, so the compiler cannot call an error.

But, we still want some sort of warning about it, as the compiler can't give one, we need another app to do it, a lint program.

>> Someone has to make a decision, that person is Walter, D is his
>> project. D  will become all that Walter makes it, plus all that we
>> contribute. My  opinion is that he's (and we are) doing a fairly good
>> job so far.
>
> Good, but not great. Get this: I believe that D has the potential to be
> truly fantastic. At its going I suspect it'll be hamstrung by its flaws,
> and become YAGI

Perhaps, time will tell.

>> There is nothing stopping you taking the D front end and writing a
>> lint-like program, I think having one, written by you, would be the
>> best  possible thing for D for several reasons:
>
> But that's the whole bleeding point. (Not swearing at you, btw.) I don't
> _want_ to write something that's going to go _against_ the standard.

AFAICS A lint program does not go _against_ the standard, in fact Walter has supported it's creation ever since I can remember.

> If
> I wanted that I'd just write a front end that gave me a boolean type,
> prevented any non-boolean subexprssions, etc. etc. But what's the point
> in that. That's not a commercial solution, it's a hobby.

It's a commmercial solution, if you write it as a lint program, eg.
change "prevented any non-boolean subexprssions" to "optionally warned of non-boolean subexprssions", Walter endorses it (which I believe he will), it gets packaged with DMD, and people start to use it.

>> 1. you're going to do your damndest (sp?) to include as many possible
>> things (like this) which you think should be done by the compiler.
>>
>> 2. you already use 10 different C++ compilers to get a series of
>> unique,  and useful warnings.
>
> I do, because I'm a pragmatist, and that's the pragmatic choice for C++.
> Were I to be presented with having to do the same thing for D, the
> pragmatic choice would be to stick to C++. (I'm serious.)

Sure, until you write the lint program some of us have been dreaming of.

>> 3. you have a good understanding of the many pitfalls and have thought
>> about how to avoid them in the best possible manner.
>>
>> The only problem being the amount of time it might take, so, perhaps
>> you  or someone else organises a team of people to work on this. I'd
>> help, but  I have a lack of spare time myself.
>
> I do plan to write such a thing in the future, just as I did for Java
> some years ago, to help with things that are outside the language, e.g.
> bracing styles, import lists, checking for doc comments, etc..

Interesting... I don't see the above examples as things a lint program does, more like they're other tools in the build process i.e. bracing styles sounds like an editor/code formatting task. dmake automatically figures out import lists. doc comments, a task for documentation generating software/app.

All this could be combined into one app, but why, when if you segregate then you can then choose from the many different incarnations of each which will no doubt spring up due to the differences in style each person has.

> I have no
> intention to do it for such fundamental things _within_ the language. If
> D needs a lint for such things, I think D will not be worth using.

Given that IMO the D compilers task is not to question code, but to compile it, provided it can be compiled, I think this issue and many like it should be handled in a lint program.

> (I
> base this on the supposition that many/most engineers do not use a lint,
> and belief that they should not have to use a lint to be able to write
> robust programs.)

I think the above belief to be based on experience with C/C++ compilers, the same is not true for D, because the D compiler does not issue warnings, it does not perform all of the same tasks as a C/C++ compiler.

I believe we can change the above attitude, with D, by supplying a D compiler and a D lint program AKA 'the nanny', I think both are seperate but essential.

Regan

Georg Wrede wrote:
> 
> 
> Matthew wrote:
> 
>> But the example itself is bogus. Let's look at it again, with a bit more flesh:
>>
>>     byte b;
>>
>>     b = 255
>>
>>     b = b + 1;
>>
>> Hmmm .... do we still want that implicit behaviour? I think not!!
> 
> 
> int big;
> big = A_BIG_LITERAL_VALUE;
> big = big + 1; // or any value at all, actually.
> 
> Where's the difference?
> 
> If somebody typed b as byte, then it's his own decision. Anyone using a small integral type has to know they can overflow -- this is no place for nannying.
> 
> Heck, any integral type might overflow.
> 
> (What I'd love is a switch for non-release code to check for overflow!)
> 
Here's one place where Ada would let you specify things properly.  If you want it to wrap, you can declare a variable of  a type that wraps.  If you want an error, you can declare a variable of a type which has a limited range.  (OTOH, if you want type promotion, you've got to take special steps to allow it...)

Why not have the compiler be able to run programs at compile time?  What I mean is that the DMD config file can have a set of (I hate to say this word) "preprocessors", programs that get run before the real compiler and get passed the same input as the compiler.
Sure, you can do this with a script - but then people won't bother.  So, in this way the compiler can remain pure - either code passes or fails, and you can enforce the running of a lint (or anyother) program transparently.  D could potentially check the return values from those programs and fail to run if any of the "preprocessors" fail.
As long as D supports different config files (ie, look for the config file in the current directory first, then /etc/dmd.conf), then you can make sure that you have global sensible options, with project specific overrides.

This is also in keeping with the philosophy that each program should do one task and do it well.  There is some lost efficiency in multiple handling of the files, but D is so fast at compiling that I think that would be minimal.

Brad

>> But the example itself is bogus. Let's look at it again, with a bit more
>flesh:
>>
>>     byte b;
>>
>>     b = 255
>>
>>     b = b + 1;
>>
>> Hmmm .... do we still want that implicit behaviour? I think not!!
>
>Yes, we do want it. Consider the following:
>
>    byte b;
>    int a,c;
>    ...
>    a = b + 1 + c;
>
>Do you really want the subexpression (b + 1) to "wrap around" on byte overflow? No. The notion of the default integral promotions is *deeply* rooted in the C psyche. Breaking this would mean that quite a lot of complicated, debugged, working C expressions will subtly break if transliterated into D. People routinely use the shorter integral types to save memory, and the expressions using them *expect* them to be promoted to int. D will just get thrown out the window by any programmer having to write:
>
>    a = cast(int)b + 1 + c;
>
>The default integral promotion rules are what makes the plethora of integral types in C (and D) usable.


#   float foo, bar;
#   ...
#   foo = bar * 2.5f;

I use a suffix to indicate that 2.5 has type float so I don'T get a warning from my C++-compiler. I could do the smae in D:

#   byte b;
#   int a,c;
#   ...
#   a = b + 1i + c;

OK your next example will be:

#   byte b,c;
#   int a,d;
#   ...
#   a = b + c + d;

But what about:

#   int b,c;
#   long a,d;
#   ...
#   a = b + c + d;

Do I have to insert a cast to prvent 'a + b' from warapping around?

-- Matthias Becker

In article <d00kbq$1bfj$1@digitaldaemon.com>, Walter says...
>
[...]
>All
>constructs in any language can result in bugs if used wrong, including
>explicit casts, and no compiler can detect them. The nirvana is to be able
>to figure out a language design that eliminates all possible error, but
>that's a research project I am not equipped to attempt.
[...]
>A cast is powerful but very blunt. It won't just do narrowing
>conversions, it will heroically attempt all sorts of things to convert the
>type. I submit that these kinds of casts can hide bugs. So far, I have not
>convinced you that this is a risk greater than 0. Running mango through this
>with warnings on will not prove that mango doesn't have such bugs in it, I
>don't know any way to automatically detect such things.

Once again, what about doing this at runtime? Like the common "missing default in a switch" error, such narrowing conversion errors can be found at runtime (and I'd add overflows):

int i = 256;
ubyte b1 = (ubyte) i; // no error: explicit cast
ubyte b2 = i; // throws NarrowCastError at runtime in debug builds

ubyte b;
for (i = 0; i < 1000; ++i)
{
..
..
b++; // throws IntegerOverflowError at runtime in debug builds
}

Ciao

It took 1.5 years of painful debugging and harrassment by users to actually get weapons working in Vega Strike (C++ and python) more than a few light seconds away from the sun because of some implicit casts from double -> float...
and believe me, trying to distinguish a double from a float multiplied by and added to several doubles is not trivial.

clearly implicit casts can cause nastier bugs than a few minutes with valgrind to find uninitialized memory or bad pointers ;-)


Matthew wrote:
> 
> Oh, come on!!
> 
> Is this truly _your_ experience, or supposition? Whichever, it is *NOT* my experience.
> 
>     I have not had an array bounds error since somewhere early last year.
>     I have not had an uninitialised variable bug since late last year.
>     I had a memory leak (one) in January (I assume this is the equiv to GC item)
>     I have had two truncation bugs last month, one of which I only found out about when running STLSoft through multiple compilers.
> 
> Now either you're representative of every other developer on the planet bar one, or I am, or we each represent but a small set of the spectrum. Of course it's the latter, which means that _you_ cannot cherry pick which issues you think matter and which do not. (Well, you can, it being your language, but you are not going to be right, and it ain't going to make D all it can be.)
> 
> Does no one else get this?!?!
> 
> 
> 

>> When I get a warning from my C++ compiler that I do a narrowing conversation I allways insert a cast.
>
>Do you mean, "after considering whether the code is correct"? If not, the you add grist to Walter's mill that narrowing errors just precipiate the careless (ab)use of casts. (Which I don't believe.)
>
Of course I check whether the code is corect or not. If I would just insert casts without looking at the code, I could turn of the warning as well.

-- Matthias Becker

Roberto Mariottini wrote:

> Once again, what about doing this at runtime? Like the common "missing default
> in a switch" error, such narrowing conversion errors can be found at runtime
> (and I'd add overflows):
> 
> int i = 256;
> ubyte b1 = (ubyte) i; // no error: explicit cast
> ubyte b2 = i; // throws NarrowCastError at runtime in debug builds
> 
> ubyte b;
> for (i = 0; i < 1000; ++i)
> {
> ..
> ..
> b++; // throws IntegerOverflowError at runtime in debug builds
> }

Petty language lawyer warning: "debug builds" in D is not really very
clear, since debug is just a special version in the D specification ?

You meant to say "non-relase builds" :-)

--anders

Sorry for the tone, had a long day at work :)

I was trying to contribute, I just fail to see what you mean with "not necessarily" (i.e. why not?), and you didn't even address the basic suggestion I made..


xs0


> These things are what's under debate. I don't believe I've defined a precise and overarching policy. Indeed, I'm suggesting that stipulating such a policy - as is currently the case with D's "all integral=>integral conversions are valid" - is a mistake.
> 
> So, pay attention, don't misrepresent, and save your sarcasm for when you have some ammo.. In the meanwhile why not try and contribute to the debate?