Wish: Variable Not Used Warning

[superdan]

Don Wrote:

> 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

cool that's great. just a nit now. you mention only logical operations there. (actually you meant bitwise operation.) but i got to thinking a bit and a few integer arithmetic operations also should be included. a / b is never larger than a (cept for signed/unsigned mixed shit). a % b is never larger than b (again save for same shit). this could go a long way making casts unnecessary. as a consequence the compiler could tighten its sphincters and become more strict about implicit casts & shit.

someone else also mentioned a < b which is fucked for mixed signs. all ordering comparisons like that are fucked and should be disabled. only == and != work for mixed signs. for the rest, cast must be required. of course if one is constant there may be no need. 

i have no idea on what to do about a + b with mixed signs. it's messed up like shit.

> That whole area needs to be tidied up. Polysemous types should really 
> help with this.

could someone care explain what this polysemous shit is (is it not polysemantic btw). the video is too vague about it. maybe this will convince andrey to haul his russian ass over here. btw thought he'd be older and more self-righteous. but i was surprised he seems a laid back dood. tries too hard to be funny tho. but he knows his shit.

> > 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.

i don't think assert(0); is cool. in a release build it disappears and that fucks the whole plan right there.

> > 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.

great! where do i sign the petition?

> > 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.

again assert(0); goes away in release mode. but wait, that's unreachable code anyway. guess that could work.

> 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.

yarp. can't tell how many times this bit my ass. in fact even "new" is bad. there should be no new.

auto c = C(crap);

then classes and structs are more inter changeable.