On Wednesday, 15 October 2014 at 02:46:05 UTC, Dicebot wrote:
> On Tuesday, 14 October 2014 at 12:33:50 UTC, IgorStepanov wrote:
>> This code tell that C is subtype of A and C is subtype of B.
>> User can use this fact in his code:
>> void foo(B);
>>
>> C c = new C;
>> foo(c); //Ok.
>> Of course, we shouldn't allow user to cast c to int:
>> int i = c; //wrong
>> However, user can explicitly cast c to his subtype, which is convertable to int:
>> int i = cast(B)c; //Ok
>> Summarizing, I disagree with suggestion disallow this code at type semantic stage.
>
> I agree. It will also make possible to break already working disambugation of `foo(c)` kind but adding new `alias this` to one of subtypes independently. That sounds annoying.

I guess the best part of D is, you have the means to fix anything you disagree with yourself... I can add a static assert to my class and be happy.

I have another idea, we could define that the shortest conversion chain wins, analogous to type promotions, that makes it possible to contain the issue inside C.

class C
{
  A a;
  B b;

  int disambiguate_int()
  {
    return a;
  }
  alias a this;
  alias b this;
  alias disambiguate_int this;
  static assert(__traits(compiles, {int _ = C.init;}), "Ambiguous alias this");
}

i.e. this assert should pass.

On Wednesday, 15 October 2014 at 03:49:41 UTC, Daniel N wrote:
> On Wednesday, 15 October 2014 at 02:46:05 UTC, Dicebot wrote:
>> On Tuesday, 14 October 2014 at 12:33:50 UTC, IgorStepanov wrote:
>>> This code tell that C is subtype of A and C is subtype of B.
>>> User can use this fact in his code:
>>> void foo(B);
>>>
>>> C c = new C;
>>> foo(c); //Ok.
>>> Of course, we shouldn't allow user to cast c to int:
>>> int i = c; //wrong
>>> However, user can explicitly cast c to his subtype, which is convertable to int:
>>> int i = cast(B)c; //Ok
>>> Summarizing, I disagree with suggestion disallow this code at type semantic stage.
>>
>> I agree. It will also make possible to break already working disambugation of `foo(c)` kind but adding new `alias this` to one of subtypes independently. That sounds annoying.
>
> I guess the best part of D is, you have the means to fix anything you disagree with yourself... I can add a static assert to my class and be happy.
>
> I have another idea, we could define that the shortest conversion chain wins, analogous to type promotions, that makes it possible to contain the issue inside C.
>
> class C
> {
>   A a;
>   B b;
>
>   int disambiguate_int()
>   {
>     return a;
>   }
>   alias a this;
>   alias b this;
>   alias disambiguate_int this;
>   static assert(__traits(compiles, {int _ = C.init;}), "Ambiguous alias this");
> }
>
> i.e. this assert should pass.

In first edition I've implemented rule, when if type defines alias this directly, this alias hides all indirect aliases with the same type. However Andrey said that we should implement the strictest rules as possible and maybe relax them later.
Thus I implemented current rules, but saved the old implemetation of search. After some time we will able to return to first rule. It's not hard.

Bump.

On Wednesday, 15 October 2014 at 09:50:17 UTC, IgorStepanov wrote:
> In first edition I've implemented rule, when if type defines alias this directly, this alias hides all indirect aliases with the same type. However Andrey said that we should implement the strictest rules as possible and maybe relax them later.
> Thus I implemented current rules, but saved the old implemetation of search. After some time we will able to return to first rule. It's not hard.

I see, in order to prevent any accidental shadowing, maybe one can consider "override alias this", if we decide to make a relaxed version in the future?

On Monday, 20 October 2014 at 00:23:46 UTC, Daniel N wrote:
> On Wednesday, 15 October 2014 at 09:50:17 UTC, IgorStepanov wrote:
>> In first edition I've implemented rule, when if type defines alias this directly, this alias hides all indirect aliases with the same type. However Andrey said that we should implement the strictest rules as possible and maybe relax them later.
>> Thus I implemented current rules, but saved the old implemetation of search. After some time we will able to return to first rule. It's not hard.
>
> I see, in order to prevent any accidental shadowing, maybe one can consider "override alias this", if we decide to make a relaxed version in the future?

Make sense. I think we should postpone but not forgotten this feature.
When main part will be merged, we will able to start discussion about override alias this.

What about the other features?

On Sunday, 19 October 2014 at 21:00:29 UTC, IgorStepanov wrote:
> Bump.

For me current description and PR look solid and safe enough to try.

On Tuesday, 21 October 2014 at 08:17:19 UTC, Dicebot wrote:
> On Sunday, 19 October 2014 at 21:00:29 UTC, IgorStepanov wrote:
>> Bump.
>
> For me current description and PR look solid and safe enough to try.

We are waiting for an Andrey's Word. Walter, as I understand haven't unresolved objections.

On 10/19/14 2:00 PM, IgorStepanov wrote:
> Bump.

I've made a few grammar and fluency edits to the DIP, and collected a few thoughts while doing that. Will get back on this before too long. -- Andrei

On Friday, 24 October 2014 at 06:04:24 UTC, Andrei Alexandrescu wrote:
> On 10/19/14 2:00 PM, IgorStepanov wrote:
>> Bump.
>
> I've made a few grammar and fluency edits to the DIP, and collected a few thoughts while doing that. Will get back on this before too long. -- Andrei

I've seen it. Thanks!
Waiting for a comments.
Should I add chapter about method overloading with alias this: it should work (and works) as cross-module overloading. It should imply
This implies from the DIP but hasn't written explicitly.

OT: Should `et\s?c\.?` be written as "etc" in English?
I thought that it should be written as "et c.", because "et cetera". Or is it an anachronism?

On Friday, 24 October 2014 at 13:05:54 UTC, IgorStepanov wrote:
> On Friday, 24 October 2014 at 06:04:24 UTC, Andrei Alexandrescu wrote:
>> On 10/19/14 2:00 PM, IgorStepanov wrote:
>>> Bump.
>>
>> I've made a few grammar and fluency edits to the DIP, and collected a few thoughts while doing that. Will get back on this before too long. -- Andrei
>
> I've seen it. Thanks!
> Waiting for a comments.
> Should I add chapter about method overloading with alias this: it should work (and works) as cross-module overloading. It should imply
> This implies from the DIP but hasn't written explicitly.
>
> OT: Should `et\s?c\.?` be written as "etc" in English?
> I thought that it should be written as "et c.", because "et cetera". Or is it an anachronism?

The convention is to write "etc.", with the period indicating that the rest of the word has been omitted. If it appears in the middle of a sentence, I don't capitalize the subsequent word as it doesn't really make sense, but I'm not sure what the actual convention is in that respect.