On 03/29/2015 07:34 PM, IgorStepanov wrote:
>
> 3. is(T: B) should raise an error if there are many ways to convert T to B.

This is inconsistent with how 'is' works otherwise, and it breaks template constraints in annoying ways. (There is no SFINAE.)

auto foo()()if(true){ return 1; } // this is the one you want
auto foo()()if(a){ return 2; }    // this is the one with is(T: B)

void main(){
    foo(); // error
}

Is the intention that no types with multiple alias this paths to some type should be defined in the first place?

On Monday, 25 May 2015 at 22:32:55 UTC, Timon Gehr wrote:
> On 03/29/2015 07:34 PM, IgorStepanov wrote:
>>
>> 3. is(T: B) should raise an error if there are many ways to convert T to B.
>
> This is inconsistent with how 'is' works otherwise, and it breaks template constraints in annoying ways. (There is no SFINAE.)
>
> auto foo()()if(true){ return 1; } // this is the one you want
> auto foo()()if(a){ return 2; }    // this is the one with is(T: B)
>
> void main(){
>     foo(); // error
> }
>
> Is the intention that no types with multiple alias this paths to some type should be defined in the first place?

This problem was discussed early, and Andrey sad that is(D: B)
should raise a error, if D can be converted to B via multiple
ways.
I mostly agree with Andrey.
The my main argument: wrong convertion shouldn't be implicitly
hidden and I suggested return true even if there are many ways to
convertion.

My example:
auto foo(T)(){ return 1; }
auto foo(T)()if(is(T: int)){ return 2; }

struct Foo
{
    //...
}
struct Bar
{
     Foo f;
     int i;
     alias i this;
}

auto ret = foo!Bar;
assert(ret == 2); //exactly the second function

After that, imagine, someone added alias intVal this to Foo.
Now there are many ways to convert Bar to int. However, user
don't know about it.

And if foo!Bar will start to return 1, it is very ugly situation.

On 05/26/2015 01:17 AM, IgorStepanov wrote:
>
>
> My example:
> auto foo(T)(){ return 1; }
> auto foo(T)()if(is(T: int)){ return 2; }
>
> struct Foo
> {
>      //...
> }
> struct Bar
> {
>       Foo f;
>       int i;
>       alias i this;
> }
>
> auto ret = foo!Bar;
> assert(ret == 2); //exactly the second function
> ...

(No, this actually raises an ambiguity error, but I see the point.)

> After that, imagine, someone added alias intVal this to Foo.
> Now there are many ways to convert Bar to int. However, user
> don't know about it.
>
> And if foo!Bar will start to return 1, it is very ugly situation.

I'm not convinced the alternative is better.

One can still do e.g.:

auto foo(T)()if(!is(typeof({static assert(is(T: int));}))){ return 1; }
auto foo(T)()if(is(typeof({static assert(is(T: int));}))){ return 2; }

On Monday, 25 May 2015 at 23:36:00 UTC, Timon Gehr wrote:
> On 05/26/2015 01:17 AM, IgorStepanov wrote:
>>
>>
>> My example:
>> auto foo(T)(){ return 1; }
>> auto foo(T)()if(is(T: int)){ return 2; }
>>
>> struct Foo
>> {
>>     //...
>> }
>> struct Bar
>> {
>>      Foo f;
>>      int i;
>>      alias i this;
>> }
>>
>> auto ret = foo!Bar;
>> assert(ret == 2); //exactly the second function
>> ...
>
> (No, this actually raises an ambiguity error, but I see the point.)
>
>> After that, imagine, someone added alias intVal this to Foo.
>> Now there are many ways to convert Bar to int. However, user
>> don't know about it.
>>
>> And if foo!Bar will start to return 1, it is very ugly situation.
>
> I'm not convinced the alternative is better.
>
> One can still do e.g.:
>
> auto foo(T)()if(!is(typeof({static assert(is(T: int));}))){ return 1; }
> auto foo(T)()if(is(typeof({static assert(is(T: int));}))){ return 2; }
Yes, we will able hack the situation: for example via __traits(compile, ...) or via is(typeof(...))
However all those hacks are known and in strange template behaviour we able to find all those places.

I think, error is not bad. Multiple alias this is a new feature, and this solution allows us to catch all error and safely try this feature. Later we will able to relax all rules, when we will sure that it is safe.

On 5/25/15 3:01 PM, IgorStepanov wrote:
> Ok, I've applied your changes to the DIP page, and I'm starting to
> rework my github PR. Sorry for the slow work (I'm very busy last time).
> However I still working. Stay on line=)

Thanks. Please get this done and let's pull it in for 068. -- Andrei

On Tuesday, 26 May 2015 at 00:03:43 UTC, Andrei Alexandrescu wrote:
> On 5/25/15 3:01 PM, IgorStepanov wrote:
>> Ok, I've applied your changes to the DIP page, and I'm starting to
>> rework my github PR. Sorry for the slow work (I'm very busy last time).
>> However I still working. Stay on line=)
>
> Thanks. Please get this done and let's pull it in for 068. -- Andrei

I've finished preparing of the github PR. Now it is ready for review.

On 5/29/15 3:37 PM, IgorStepanov wrote:
> On Tuesday, 26 May 2015 at 00:03:43 UTC, Andrei Alexandrescu wrote:
>> On 5/25/15 3:01 PM, IgorStepanov wrote:
>>> Ok, I've applied your changes to the DIP page, and I'm starting to
>>> rework my github PR. Sorry for the slow work (I'm very busy last time).
>>> However I still working. Stay on line=)
>>
>> Thanks. Please get this done and let's pull it in for 068. -- Andrei
>
> I've finished preparing of the github PR. Now it is ready for review.

So https://github.com/D-Programming-Language/dmd/pull/3998 is the one? -- Andrei

On Friday, 29 May 2015 at 21:41:12 UTC, Andrei Alexandrescu wrote:
> On 5/29/15 3:37 PM, IgorStepanov wrote:
>> On Tuesday, 26 May 2015 at 00:03:43 UTC, Andrei Alexandrescu wrote:
>>> On 5/25/15 3:01 PM, IgorStepanov wrote:
>>>> Ok, I've applied your changes to the DIP page, and I'm starting to
>>>> rework my github PR. Sorry for the slow work (I'm very busy last time).
>>>> However I still working. Stay on line=)
>>>
>>> Thanks. Please get this done and let's pull it in for 068. -- Andrei
>>
>> I've finished preparing of the github PR. Now it is ready for review.
>
> So https://github.com/D-Programming-Language/dmd/pull/3998 is the one? -- Andrei
Yep.

Hello, comrades. Lets put into the schedule reviewing of this PR (https://github.com/D-Programming-Language/dmd/pull/3998).
It contains a very much changes and it is hard to maintain its performance: each foreign PR may break it.