On 2/12/12, David Nadlinger <code at klickverbot.at> wrote:
> Personally, I certainly wouldn't expect..

Well I guess it's not so much "expecting" as it's undefined behavior that used to work and something I got used to doing. Of course it being undefined didn't stop me from using it, so much in D is either undocumented or underdocumented or wrongly documented.. I guess I wrongly assumed selective imports would be "preferred" over other symbols.

Maybe this issue wouldn't be so problematic if phobos wasn't an ever-increasing collection of clashing symbol names, heh!

To further drive the point home:

import std.algorithm;
import std.utf : count;

alias std.utf.count count;  // *error* in 2.057, *required* in 2.058:

void main()
{
    "1".count;
}

Without the alias, it's ok in 2.057, but error in 2.058.

In 2.057 if I already had selective imports I couldn't use an alias because of an existing compiler bug. So I can't easily keep compatibility between 2.057 and 2.058 without maybe using static imports.

Anyway, the point is not that the old behavior was ok, but that these major bugs have to be fixed ASAP and not be delayed so much since they end up wreaking havoc on user code.

On Sun, 12 Feb 2012 22:58:26 +0100, Andrej Mitrovic <andrej.mitrovich at gmail.com> wrote:

> Why does this not work anymore?
>
> module test;
>
> import std.algorithm;
> import std.utf : count;
>
> void main()
> {
>     "a".count();
> }
>
> test.d(8): Error: std.utf.count!(char).count at
> D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\utf.d(1757) conflicts
> with std.algorithm.count!("true",string).count at
> D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(4551)
>
> Selective imports used to make these conflicts go away. What changed?
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta

Your bug is part of a series of regressions introduced with the new
Import lookup (see my post in "[dmd-beta] D2 2.058 beta").
Selective imports are bound into the current namespace.
This means they are resolved before import lookup kicks in and
it also means that they overload against your modules symbols (if
overloadable).

David Nadlinger, el 12 de febrero a las 23:08 me escribiste:
> On 2/12/12 10:58 PM, Andrej Mitrovic wrote:
> >Why does this not work anymore?
> >
> >module test;
> >
> >import std.algorithm;
> >import std.utf : count;
> >
> >void main()
> >{
> >     "a".count();
> >}
> >
> >test.d(8): Error: std.utf.count!(char).count at
> >D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\utf.d(1757) conflicts
> >with std.algorithm.count!("true",string).count at
> >D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(4551)
> >
> >Selective imports used to make these conflicts go away. What changed?
> 
> Personally, I certainly wouldn't expect selective imports to resolve conflicts, but what changed is that they were previously implemented using the equivalent of an explicit AliasDeclaration internally, which thus used to resolve the conflict.

Look similar to http://d.puremagic.com/issues/show_bug.cgi?id=7373. In that case I asked if renamed imports were supposed to resolve conflicts and the answer was yes (and I agree) and the bug was fixed. I think it would be best to be consistent with selective and renamed imports and make them resolve conflicts. After all you are asking for a specific symbol, I can't see why an implicitly imported symbol should conflict with that when the intention is pretty clear.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
careful to all animals (never washing spiders down the plughole),
keep in contact with old friends (enjoy a drink now and then),
will frequently check credit at (moral) bank (hole in the wall),

On 02/12/2012 09:56 PM, Mike Wey wrote:
> On 02/12/2012 09:08 PM, Walter Bright wrote:
>>
>> It's a Base, not an Object. It can be converted to an Object.
>
> Doesn't that break Polymorphism?
>
> You should be able to use Base as if it is an Object without a cast.
>
>
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta

According to the documentation a == b is rewritten to
.object.opEquals(a, b); if a  and b are both objects.
And while .object.opEquals(new Base(), new Base()); compiles without an
error, and gives the expected result at runtime. using == is an
compiletime error when a opCast is supplied without adding one for Object.

Base being derived from Object there would be no need for a cast when you want to use it as an Object.

Adding an opCast overload for Object solves the compiletime error but, the added opCast doesn't do anything:

Base opCast(T)()
     if ( is(T == Object) )
{
     return this;
}

Yes i used Base as the return type, that works because base is derived from Object.

Is the behavior of the beta really correct?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20120213/5046af9a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug.d
Type: text/x-dsrc
Size: 445 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20120213/5046af9a/attachment-0001.d>