Andrei Alexandrescu: Sorry for the late reply.
I think this is a reframing we should shun because it switches the focus from "what is the usefulness of this" to "what is the difficulty of putting up with it".
Jonathan was (rightfully) presenting the implementation problems, so I have had the right to answer to those. I agree with you that the absence of implementation problems can't justify the introduction of a feature, but the presence of implementation problems can decrease the appealing of a new feature. So talking about implementation problems in such discussions is legitimate.
The point here is demonstrating how helpful the feature is in writing good quality code.
Right. And unfortunately it's not easy to do.
In my time I've seen this warning helping here and there, but I'd be hard pressed to convince myself or someone that it really adds value. It's one of the most frequent _innocuous_ warnings I see in third-party software when I compile it.
By itself the presence of such warning does not denote a bug. On the other hand in my C code sometimes I have put some variables that later I have forgotten to use. Such GCC warning has probably avoided me some mistakes. So I appreciate such warning in D too.
Furthermore, I just googled ``go unused variables'' and guess what the first entry was: https://groups.google.com/forum/?fromgroups=#!topic/golang-nuts/OBsCksYHPG4
The situation is not exactly the same. This part of the discussion was about a warning (or two warnings, one for unused variables and one for unused last assignment to variables), while in Go that's an error and it can't be disabled.
I agree that in some cases, while you are writing the code, you sometimes want to introduce temporary debugging variables, that may or may not be really used. In such case you don't enable those warning(s). You enable them a little later when you polish the code.
Bye, bearophile
