Naming conventions for functions in similar modules

[KennyTM~]

On Jun 23, 11 01:16, Andrei Alexandrescu wrote:
> On 6/22/11 11:53 AM, Walter Bright wrote:
>> On 6/22/2011 4:47 AM, Lars T. Kyllingstad wrote:
>>> One problem: std.uni only contains functions for dealing with upper/
>>> lower case and for checking whether something is an alpha character. If
>>> you want the other functions, such as isDigit(), isPunctuation(), etc.
>>> you still have to import std.ascii. And once you have imported both
>>> std.uni and std.ascii, you are forced to disambiguate every time you
>>> call
>>> a function which exists in both.
>>
>> True, but I don't see much of an improvement of:
>>
>> toAsciiLower()
>>
>> over:
>>
>> std.ascii.tolower()
>>
>> at least as far as typing goes.
>
> One improvement would be to relax package lookup such that
> ascii.tolower() is a synonym for std.ascii.tolower. That way everything
> works reasonably nice out of the box.
>
>
> Andrei

So

     import std.net.isemail;
     void main() {
        isEmail("1");             // currently ok.
        isemail.isEmail("2");     // Andrei's proposal
        net.isemail.isEmail("3"); // ok???
        std.net.isemail.isEmail("4"); // currently ok.
     }

Also, if allowing 'ascii.toLower', will the symbol 'ascii' itself be 
available as well?

     import std.ascii;
     void main() {
       pragma(msg, std.ascii);  // currently ok.
       pragma(msg, ascii);      // ok???
     }

because if it is available, then 'std.string' needs to be renamed, but 
if it is not available, it looks asymmetric.