About Go, D module naming

[bearophile]

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