On Friday, 24 October 2014 at 13:17:28 UTC, Meta wrote:
> 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.

A full stop (a.k.a. period in some countries) for abbreviation does not imply that the following word must be capitalised. Sentences must start with a capital.

On Friday, 24 October 2014 at 13:17:28 UTC, Meta wrote:
> 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.

Thanks for the explanation:)

On 10/21/14 1:24 PM, IgorStepanov wrote:
> 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.

There are issues with the proposal. I must get to them today. -- Andrei

On 10/24/14 6:05 AM, 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.

Coming soon. I've been under quite a bit of pressure as of late.

> 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.

Interesting. I think it should work like overloading of calls in base and derived classes.

> 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?

You can't go wrong with M-W: http://www.merriam-webster.com/dictionary/etc


Andrei

On Tuesday, 28 October 2014 at 02:07:23 UTC, Andrei Alexandrescu wrote:
> On 10/24/14 6:05 AM, 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.
>
> Coming soon. I've been under quite a bit of pressure as of late.
>
>> 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.
>
> Interesting. I think it should work like overloading of calls in base and derived classes.

Not really. Rules which define overloading class methods doesn't describe multiple inheritance case.
In single inheritance case alias this rule is similar with inheritance rule: derived overload set hides base base overload set:

struct A
{
    void foo(string)
    {
        writeln("string");
    }

    void foo(int)
    {
        writeln("int");
    }
}

struct B
{
    void foo(double)
    {
        writeln("double");
    }

    A a;
    alias a this;
}

B b;
b.foo("string"); //error
b.foo(42); //called B.foo(double), not B.a.foo(int);

The second test is not similar to inherintance rules, but this case is not relevant with multiple alias this and it is already done.

When I said "cross-module overloading", I told about case when C inherits (via alias this) A and B, both A and B have "foo" methods with different paramethers and compiler should resolve foo call:

struct A
{
    void foo(string)
    {
        writeln("string");
    }

    void foo(int)
    {
        writeln("int");
    }
}


struct B
{
    void foo(double)
    {
        writeln("double");
    }
}

struct C
{
     A a;
     B b;
     alias a this;
     alias b this;
}

C c;
c.foo("str"); // OK, c.a.foo(string)
c.foo(4.2); //OK, c.b.foo(double);
c.foo(42); //Error: c.a.foo(int) or c.b.foo(double)?

BTW, similar case with multiple inheritance via interfaces works absolutely incorrect:

interface CA
{
    final void foo(string)
    {
        writeln("string");
    }

    final void foo(int)
    {
        writeln("int");
    }
}

interface CB
{
     final void foo(double)
     {
         writeln("double");
     }
}

class CC : CA, CB
{

}

auto cc = new CC();
cc.foo("xxx"); //OK, called CA.foo(string)
cc.foo(42); //called CA.foo(int) without any warnings
cc.foo(4.2); //Error: unable to call CA.foo with double argument.

In other words, compiler choses the first base interface, uses its overload set and ignores other interfaces.

>> 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?
>
> You can't go wrong with M-W: http://www.merriam-webster.com/dictionary/etc

Thanks.

On 10/10/14 10:09 AM, IgorStepanov wrote:
> I've created DIP for my pull request.
> DIP: http://wiki.dlang.org/DIP66
> PR: https://github.com/D-Programming-Language/dmd/pull/3998
>
> Please, comment it.

Here's my destruction:

* "symbol can be a field or a get-property (method annotated with @property and taking zero parameters)." -> actually:

(a) the @property annotation is not necessary
(b) there may be one ore more parameters so long as they're all defaulted

So the text should be "obj.symbol must be a valid expression".

* "At the AliasThis declaration semantic stage, the compiler can perform the initial checks and reject the obviously incorrect AliasThis declarations." -> it might be simpler (for the sake of simplifying generic code) to just delay all error checking to the first use.

* I don't think the pseudocode helps a lot. Better let's have a clear and precise specification (I've edited the lookup order into an ordered list).

* Regarding the lookup, opDispatch shouldn't come before alias this, or should come before base class lookup. Essentially alias this is subtyping so it should enjoy similar privileges to base classes. A different way to look at it is opDispatch is a "last resort" lookup mechanism, just one step above the UFCS lowering.

* The DIP should specify the working of alias this as rewrites/lowerings, not pseudocode. Basically for each kth declaration "alias symbolk this;" the compiler rewrites "obj.xyz" as "obj.symbolk.xyz" and then does the usual lookup on that expression. That means the whole algorithms is applied again etc. If more than one rewrite typechecks, that's an ambiguity error.

* IMPORTANT: The DIP must discuss rvalue vs. lvalue cases. The rewrite approach simplifies that discussion because it's clear what happens by simply reasoning about the rewritten expression. Lvalue vs. rvalue matters a lot practically. Consider:

struct A
{
    private int x;
    alias x this;
}

struct B
{
    private int _x;
    int x() { return x; }
    alias x this;
}

Then x can be passed by reference, modified directly etc. for A but not for B.

===========

Congratulations on taking this to a DIP. It clarifies things really nice and it's an example to follow for future language changes.


Andrei

On Tuesday, 28 October 2014 at 19:45:09 UTC, Andrei Alexandrescu wrote:
> On 10/10/14 10:09 AM, IgorStepanov wrote:
>> I've created DIP for my pull request.
>> DIP: http://wiki.dlang.org/DIP66
>> PR: https://github.com/D-Programming-Language/dmd/pull/3998
>>
>> Please, comment it.
>
> Here's my destruction:
>
> * "symbol can be a field or a get-property (method annotated with @property and taking zero parameters)." -> actually:
>
> (a) the @property annotation is not necessary
> (b) there may be one ore more parameters so long as they're all defaulted
>
> So the text should be "obj.symbol must be a valid expression".
>
> * "At the AliasThis declaration semantic stage, the compiler can perform the initial checks and reject the obviously incorrect AliasThis declarations." -> it might be simpler (for the sake of simplifying generic code) to just delay all error checking to the first use.
>
> * I don't think the pseudocode helps a lot. Better let's have a clear and precise specification (I've edited the lookup order into an ordered list).
>
> * Regarding the lookup, opDispatch shouldn't come before alias this, or should come before base class lookup. Essentially alias this is subtyping so it should enjoy similar privileges to base classes. A different way to look at it is opDispatch is a "last resort" lookup mechanism, just one step above the UFCS lowering.
>
> * The DIP should specify the working of alias this as rewrites/lowerings, not pseudocode. Basically for each kth declaration "alias symbolk this;" the compiler rewrites "obj.xyz" as "obj.symbolk.xyz" and then does the usual lookup on that expression. That means the whole algorithms is applied again etc. If more than one rewrite typechecks, that's an ambiguity error.
>
> * IMPORTANT: The DIP must discuss rvalue vs. lvalue cases. The rewrite approach simplifies that discussion because it's clear what happens by simply reasoning about the rewritten expression. Lvalue vs. rvalue matters a lot practically. Consider:
>
> struct A
> {
>     private int x;
>     alias x this;
> }
>
> struct B
> {
>     private int _x;
>     int x() { return x; }
>     alias x this;
> }
>
> Then x can be passed by reference, modified directly etc. for A but not for B.
>
> ===========
>
> Congratulations on taking this to a DIP. It clarifies things really nice and it's an example to follow for future language changes.
>
>
> Andrei

Thanks for answer, I hope, I'll able to to carefully consider your comments tomorrow.

Now I want to ask about the one thing.
What do you think about compatibility with existing alias this implementation?

For example you wrote: "Regarding the lookup, opDispatch shouldn't come before alias this, or should come before base class lookup.".
This requirement breaks the existing code.
We can apply this change in DIP, however if we want to apply this change to compiler, we should be careful. Moreover, I don't see the way to create deprecation path: old implementation->deprecated old implementation & new inmplementation -> prohibited old implementation & new inmplementation.

If we will change the semantic order of proprerty resolving, we will not able to warn user about changes. Suddenly his code will be compiled in a different way.

And please comment my way to resolving "is" expression via alias-this:
http://forum.dlang.org/thread/ubafmwvxwtolhmnxbrsf@forum.dlang.org?page=5

Thanks for the DIP review.

On Tuesday, 28 October 2014 at 20:09:07 UTC, IgorStepanov wrote:
> And please comment my way to resolving "is" expression via alias-this:
> http://forum.dlang.org/thread/ubafmwvxwtolhmnxbrsf@forum.dlang.org?page=5

Something else related to the discussion about `is` from this thread: http://forum.dlang.org/post/tulvmydnogbgebnxybfk@forum.dlang.org. The following code:

import std.math;
import std.traits;

struct S(T)
if(isFloatingPoint!T)
{
    T val;
    alias val this;
}

void main()
{

    auto s = S!float();
    assert(isNaN(s));
    s = 10.0;
    assert(!isNaN(s));
}

Current fails to compile with this error:

Error: template std.math.isNaN cannot deduce function from
argument types !()(S!float), candidates are:

std/math.d(4171):        std.math.isNaN(X)(X x) if
(isFloatingPoint!X)

Is this a problem with the current implementation of `alias this`, or should isFloatingPoint be changed so that it also accepts types that alias a floating point type?

On Tuesday, 28 October 2014 at 21:55:35 UTC, Meta wrote:
> or should isFloatingPoint be changed so that it also accepts types that alias a floating point type?

My mistake, I mean isNaN and similar functions, such as isNumeric.

On Tuesday, 28 October 2014 at 21:55:35 UTC, Meta wrote:
> On Tuesday, 28 October 2014 at 20:09:07 UTC, IgorStepanov wrote:
>> And please comment my way to resolving "is" expression via alias-this:
>> http://forum.dlang.org/thread/ubafmwvxwtolhmnxbrsf@forum.dlang.org?page=5
>
> Something else related to the discussion about `is` from this thread: http://forum.dlang.org/post/tulvmydnogbgebnxybfk@forum.dlang.org. The following code:
>
> import std.math;
> import std.traits;
>
> struct S(T)
> if(isFloatingPoint!T)
> {
>     T val;
>     alias val this;
> }
>
> void main()
> {
>
>     auto s = S!float();
>     assert(isNaN(s));
>     s = 10.0;
>     assert(!isNaN(s));
> }
>
> Current fails to compile with this error:
>
> Error: template std.math.isNaN cannot deduce function from
> argument types !()(S!float), candidates are:
>
> std/math.d(4171):        std.math.isNaN(X)(X x) if
> (isFloatingPoint!X)
>
> Is this a problem with the current implementation of `alias this`, or should isFloatingPoint be changed so that it also accepts types that alias a floating point type?

You may see isFloatingPoint declaration in traits.d:
enum bool isFloatingPoint(T) = is(FloatingPointTypeOf!T) && !isAggregateType!T;

This template explicitly says that T shouldn't be an aggregate type. Thus
std.math.isNaN(X)(X x) if (isFloatingPoint!X)
shouldn't accept a struct.