UFCS for D

[foobar]

On Friday, 30 March 2012 at 10:22:18 UTC, Walter Bright wrote:
> On 3/30/2012 2:15 AM, Nick Sabalausky wrote:
>>> Andrei and I have  talked about it, and we think it is 
>>> because of
>>> difficulties in breaking a module up into submodules of a 
>>> package.
>>> We think it's something we need to address.
>>
>> Eh? Other people have voiced concerns over that since waaay 
>> back in even
>> pre-D1 times. In particular, many people have argued for 
>> allowing modules
>> with the same name as a package. Ie: you could have both 
>> module "foo" and
>> module "foo.bar". The reasons they gave for wanting this are 
>> right along the
>> lines of what you're talking about here. Eventually they got 
>> the message
>> that it wasn't gonna happen and they gave up asking for it.
>>
>> Or is there a separate problem you're refering to?
>
> No, that's it. What brings it to the fore is, as I said, the 
> kitchen-sink module that is becoming prevalent.

I'm confused. I thought that The kitchen-sink approach was a 
deliberate design decision. I also don't see how the language is 
at fault here - some libraries opted for a all.d module that 
public imports the other modules which cleanly solves the problem.

This can be trivially solved by a convention of adding a _.d or 
all.d or whatever agreed upon module at the package level. Sure, 
the above mentioned enhancement will remove the need for this 
extra tiny step. But this is merely eliminating a minor 
inconvenience, not some huge flaw of the language that prevents 
good design and proper organization.