Wish: Variable Not Used Warning

[Era Scarecrow]

> In "C++'ish" / D way, this is normally dealt
> like this:
> 
> int isPrime(int number, int[] /*primesList*/)
> {
> 	//int cnt;
> 
> 	return 0;
> }
> 
> Hard & ugly? I think warnings are not meant to be used
> to remember you 
> that you have something unfinished. I regularly tag those
> parts with "//
> todo", which is easily grep'd from code.

Maybe in that instance no it isn't hard or ugly. However if i had continued and partially implimented, you need it enabled, but enabled doesn't help much since you can't get to it.

//returns true/flase if a prime. 
bool isPrime(int number, int[] primesList)
{
	int cnt;
	bool prime = true;

	primesList = null;	//disable for now. When fully implimented, remove

	if (primesList)	//gives an error since it never executes, but logic is there.
	{
		foreach (pnum; primesList)
		{
		//finish later
		}

	}
	else
		for (cnt = 2; cnt < number; cnt++)
			if (number % cnt == 0)
				prime=false;


	return prime;
}

 Being partially implimented, i don't really want to comment out large areas of my code, since i want to know if i wrote it wrong, or right. I'll in the middle of my project, make sure all my block openings/closings are good, and then compile the code, which i will never run but instead i use the errors and warnings to find certain bugs and simple problems earlier, rather then do an entire file and then trace all the bugs all at once.

 Or am i doing it wrong?

> It is not about consuming memory, it's about compiling
> code that won't 
> work. It is not about making intentionally dead code,
> it's about 
> accidentally having dead code.

 Agreed. truely dead code should reply an error. 

> Because syntactic salts and more pedantic checkings save a
> lots of 
> debugging time.
> 
> >  It was these very things that kept me from learning
> C++, because it was
> >  too hard for me to grasp because it was ugly, and i
> don't want to make
> >  something ugly.
> 
> Warnings & checkings does not make C++ ugly :)

 No, i mean the :: operator, and other details in the language. Sorry for the confusion there.

> Constant conditionals:
> 
> > const DEBUG = 0;
> > 
> > ..
> > 
> > if (DEBUG) {
> >     //put debugging information
> > }
> 
> 1) Use static if?

 Still learning D, i've seen references of static if's but i haven't read enough on it yet.

> 2) Anyway, it is not constant conditional in that way that
> it is normally 
> warned - you have intentionally set the value so, and thus
> the compiler 
> could optimize the dead code away without problem. Normally
> it is warned, 
> if you have an expression:
> 
> 	for(...; (a + b) < 8; ...) { ... }
> 
> ...if the compiler recognizes, that the condition cannot
> never be 
> anything else than true or false, do you think it is
> intentional?

 if it was truely intentional, then wouldn't you do..?

for (;;){}
	or
while(true){}

 if it wasn't intentional, then you were trying to actually check for something.

> 
> > while(1)    //always true
> > {
> >     if (someCondition){
> >         break;
> >     }
> > }
> 
> The same hold here; "while(true)",
> "for(;;)" are intentionally written to 
> be infinite loops. I regularly define in C/C++:

those are truely intentional, a contition should actually have a chance to change and be true/false at different steps, correct?

> #define forever for(;;)
> 
> I really don't mean, that the "warning
> system" should be something like 
> "code smelling analyzing" for refactoring, but I
> think that most of those 
> basic things could easily be catched at compile time (w/
> warnings) 
> without any negative side effects.