Wish: Variable Not Used Warning
Don
nospam at nospam.com.au
Fri Jul 11 05:01:19 PDT 2008
superdan wrote:
> Nick Sabalausky Wrote:
>
>> As just a few examples:
>> http://www.digitalmars.com/d/1.0/warnings.html
>
> yarp i'm so happy you sent those. let's take'em 1 by 1. please let me know agree or disagree.
>
> 1. warning - implicit conversion of expression expr of type type to type can cause loss of data
>
> it's a shame this is allowed at all. any conversion that involves a loss must require a cast right there. as far as the example give goes:
>
> byte a, b;
> byte c = a + b;
>
> compiler can't know a + b is in byte range so a cast is good. but take this now:
>
> byte c = a & b;
>
> in this case the compiler must accept code. so what i'm saying is that better operator types will help a ton.
That's in bugzilla.
http://d.puremagic.com/issues/show_bug.cgi?id=1257
That whole area needs to be tidied up. Polysemous types should really
help with this.
> 3. warning - no return at end of function
>
> now what a sick decision was it to accept that in the first place. an overwhelming percentage of functions *can* and *will* be written to have a meaningful return at the end. then why the fuck cater for the minority and hurt everybody else. just require a return or throw and call it a day. people who can't return something meaningful can just put a throw. code growth is negligible. impact on speed is virtually nil. why the hell do we even bother arguing over it.
Yup.
return should be required, unless function contains inline asm.
Otherwise manually put assert(0); at the last line.
> 4. warning - switch statement has no default
>
> another example of a motherfuck. just require total coverage. in closed-set cases i routinely write anyway:
>
> switch (crap)
> {
> case a: ...; break;
> case b: ...; break;
> default: assert(crap == c): ...; break;
> }
>
> again: vast majority of code already has a default. the minority just has to add a little code. make it an error.
Yup. Make it an error.
>
> 5. warning - statement is not reachable
>
> this is a tad more messy. people routinely insert a premature return in there to check for stuff. it pisses me off when that won't compile. i discovered i could do this:
>
> if (true) return crap;
>
> that takes care of the error. and i think it's actually good for me because it really is supposed to be temporary code. it jumps at me in a review. as it should.
You can also put assert(0); at the top of the unreachable code.
2,3, and 4 should definitely be errors.
I also think that uninitialised class variables should be a compile-time
error. It's a horrible newbie trap, especially for anyone with a C++
background:
-------------
class C {
void hello() { writefln("Hello crashing world"); }
};
void main() {
C c; // should be illegal
c.hello();
}
--------------
My first D program using classes was somewhat like that; took me ages to
work out why it was segfaulting at runtime. It's still the most common
mistake I make.
You should have to write C c = null; for the rare cases where you really
want an uninitialised class.
More information about the Digitalmars-d
mailing list