the point of selective importing

[Dave]

Lars Ivar Igesund wrote:
> Jari-Matti Mäkelä wrote:
> 
>> Lars Ivar Igesund wrote:
>>> I believe I might have been a bit rash here, but I got somewhat pissed
>>> pouring over all the posts for the last few days. I will therefore
>>> restate some of my thoughts in a calmer manner:
>>>
>>> If we for a second ignore the language issues chatted about recently,
>>> most people agree that D is missing libraries to be able to really
>>> compete with other languages. It is therefore unfathomable to me why you
>>> Walter don't actively try to make it easy to create good libraries in D.
>>> Libraries that can be made stable, failsafe and predictable. You have
>>> said many enough times that D is different enough to need different
>>> solutions to problems already solved in other languages. Why is it then
>>> that you seemingly refuse to listen to those that have tried to solve
>>> these problems in D over the years? Those that have found that the
>>> language features in D probably need to be refined to not only make
>>> libraries in D possible, but fun to write, fun to use, safe to use and
>>> with a predictable usage pattern.
>> I think you're a bit too harsh on Walter now. In the recent two week or
>> so Walter has fixed many important things like most of the import bugs.
>> The only thing left are:
>>
>>  * some people thing that imports should be private by default
>>    - changing this would break some old code, but does it matter?
>>     (statistically private imports are much more common)
>>
>>  * most of the people want an additional safe import syntax that allows
>> importing to a custom namespace.
>>
>>  * some general show-stopper bugs
>>
>> The first two of these are luckily easy to fix. We're not far from 1.0.
>> If were not in a hurry, I would like the interface things to be fixed
>> (that double lookup implementation) too before reaching stable. Then D
>> will be perfect for real production level use.
>>
> 
> Ah, maybe I was still too harsh, but I've been around for a while, and we're
> not talking new issues. That it really is mostly all about easy fixes,
> don't make it any more sensible to me that they haven't already been made,
> or why he keep suggesting fixes so cumbersome that noone will use them.
> 

That's what it boils down to. import-and-alias(*) in one step (vs. 
specific symbol import or both) seems relatively easy to implement and 
any more argument against that alone just seems silly.

Then there's the specific symbol import that C# (and Perl and Python) 
allow. I could see where perhaps this would be tougher to implement but 
I think is well worth it; given large libraries and long namespaces it 
can really make code easier to build, debug and maintain.

Like Kris though, I'd settle for the first, at least for v1.0.

* import std.stdio stdio; // std.stdio imported and aliased as stdio