[dmd-beta] Time for a new beta?

[Rainer Schuetze]

On 21.08.2011 00:10, Nick Sabalausky wrote:
> From: "Dmitry Olshansky" <dmitry.olsh at gmail.com>
>> On 20.08.2011 12:39, Rainer Schuetze wrote:
>>> 3. I tried to remove some more (currently soft) deprecation messages 
>>> regarding std.ctype, and it turned out that it was a bit of a hassle 
>>> to get it to compile because I had to mix both std.ascii and 
>>> std.uni. This is happening because I'd like to use the isAlpha from 
>>> std.uni, but there are other functions missing from std.uni (like 
>>> isDigit, isHexDigit, etc.).
>>>
>>> I think this was discussed before, but I'm not sure what the 
>>> conclusion was. I suggest adding some forwarding aliases to std.uni 
>>> for function that have identical implementation, and ensure that the 
>>> compiler does not complain about ambiguities if these are just 
>>> aliases to the same symbol.
>>>
>> Recalling last discussion on this, the users have to solve this on 
>> their own. Be it use unicode everywhere or full 
>> std.ascii.xxx/std.uni.xxx or whatever. I ended up using renamed imports.
>>
>
> There's a simple alias trick that works very well for that sort of thing:
>
> ------------------------
> module m1;
> void a() {};
> void b() {};
> ------------------------
> module m2;
> void b() {};
> void c() {};
> ------------------------
> module main;
> import m1
> import m2;
>
> // Nifty trick: Pull m1's b() into local scope,
> // effectively"prioritizing" it.
> private alias m1.b b;
>
> void main() {
>    b(); // Works: Calls m1.b()
> }
> ------------------------
>

I'm not too happy with that solution:
- you have to add these aliases in every module with ambiguities.
- you get even more ambiguities if you import the module with the 
additional aliases. Even if private were working as specified, overload 
resolution happens before protection checks (which does not seem like 
the best idea to start with).

I've used a combination of selective imports and full module 
specification for now.

Thanks,
Rainer