Re: defvars at compile time

[Stefan Monnier]

>> Well, I'd have to strongly disagree with "have to".  Nothing forces you to
>> remove all compilation warnings for all supported emacsen.
> Not in Emacs perhaps, but MH-E conventions require it.

Well, that's your choice, of course.

> And I'd argue that it should be required in Emacs as well.

I'd strongly oppose it.  I could OTOH accept a policy that Emacs packages
should not output any warning when compiled with the Emacs version that they
come with.  Because then we have a lot more freedom to fix the problematic
warning either in the package, or in byte-compiler, or ...

>> It's much worse than that.  It's fundamentally wrong to make code less
>> readable for the sake of compiler warnings.  Compiler warnings are there to
>> help you find bad code and improve it.
> Assuming you find the warning.  The problem with a forest of compiler
> warnings is that warnings you might want to see are hidden.  Because
> MH-E code compiles clean, if an error or warning appears, it stands
> out loud and clear.

That doesn't contradict what I said.

> Asking how to write code that doesn't generate compiler warnings is a
> legitimate question. If you can suggest a clean way to do this, we'll
> do it.

As mentioned, for your original problem, the byte-compiler was fixed so it
doesn't generate a warning for this code any more.  For that particular
problem, it is *the* clean way to fix the warning.  If you want to eliminate
the warning without allowing yourself this clean fix (e.g. by insisting
dogmatically that all warnings must go, even when compiling with some older
byte-compiler), you'll end up with uglier and less maintainable code.


        Stefan