Multi alias this is still not implemented. At this point of time I might as well  create a pr request that deprecate the alias this feature as it quite clearly that walter doesn't like it and hates implicit conversion for user types in general irregardless of design.


-Alex

On Friday, 26 July 2019 at 01:27:01 UTC, 12345swordy wrote:
> Multi alias this is still not implemented. At this point of time I might as well  create a pr request that deprecate the alias this feature as it quite clearly that walter doesn't like it and hates implicit conversion for user types in general irregardless of design.
>
>
> -Alex

I don't think that's the way to affect change, and your PR will just be closed, or worse, ignored.  We can't deprecate `alias this` (at least in the near-to-medium term), but we may be able to provide alternatives.

Andrei mentioned in a previous post that we've been too worried about making changes (https://forum.dlang.org/post/q7j3s0$15n7$1@digitalmars.com), and he advocated for changes that are "addition only".  Of course, such changes still need to carry their weight, but it may be possible to add a feature to the language that is superior to `alias this` allowing it to gradually fall out of fashion, and in the long term, deprecated.

If you want to move D forward in this regard, you have to strategize and make a good case for your changes.  It's quite difficult, but also quite possible if you remain diplomatic and professional.

Timing also plays a role.  I believe Walter accepted some of my PRs for optional runtime features because he was also working on betterC at the time and those changes were congruent with his priorities at the time.

I'm working on a proposal for `alias this`, but I need to make a strong case for it, and that can take a lot of time and effort.  I know you had some ideas for making `opImplicitCast` more appealing.  I'd be interested in hearing more about that, and if I think it will help my case, I'll incorporate them.

Think about what it is that Walter cares about and consider how your proposal can provide him something he's been wanting.  I think Walter is concerned about language and compiler complexity.  There may be an opportunity there to improve the `alias this` implementation so the language and compiler will be less complex, and that may earn his support.

It's true that once Walter has an idea in his head, it's extremely difficult to change his mind, but he's also not the only one that needs convincing.  With a well-written DIP, and a strong case, Atila may get on board and provide the support needed to approve the feature.

Mike

On Friday, 26 July 2019 at 01:53:18 UTC, Mike Franklin wrote:
> On Friday, 26 July 2019 at 01:27:01 UTC, 12345swordy wrote:
>> [...]
>
> I don't think that's the way to affect change, and your PR will just be closed, or worse, ignored.  We can't deprecate `alias this` (at least in the near-to-medium term), but we may be able to provide alternatives.
>
> [...]

Do you have a draft already regarding this on github? I don't mind helping creating the dip.

-Alex

On Friday, 26 July 2019 at 11:54:51 UTC, 12345swordy wrote:

> Do you have a draft already regarding this on github? I don't mind helping creating the dip.

No, I'm sorry.  I'm still collecting information and exploring ideas to build my case.  You mentioned in on one of the recent PRs that you believe something like `opImplicitCast` could be implemented without some of the drawbacks present in C++'s implementation.  I'm interested in your ideas.

I need to make a strong case, so I'm exploring how to motivate my idea and I'm trying to discover any holes in it.  There's also a DMD bug I'd like to resolve before submitting a DIP.

In general, my idea is to create a more limited `alias this`-like feature that will eliminate some of the "weird sh**" that comes with `alias this` and only keep the good stuff.  Whatever's left can be implemented with D's existing metaprogramming facilities.

I believe it could be approved because it will significantly reduce the compiler's implementation and avoid a lot of bad interactions.  I think that would be appealing to Walter and others.

If you want to discuss it you're welcome to contact me on Slack, Discord, or IRC under the handle JinShil and I'll give you all the details of what I have in mind.

Mike

On Friday, 26 July 2019 at 12:07:04 UTC, Mike Franklin wrote:
> On Friday, 26 July 2019 at 11:54:51 UTC, 12345swordy wrote:
>
>> Do you have a draft already regarding this on github? I don't mind helping creating the dip.
>
> No, I'm sorry.  I'm still collecting information and exploring ideas to build my case.  You mentioned in on one of the recent PRs that you believe something like `opImplicitCast` could be implemented without some of the drawbacks present in C++'s implementation.  I'm interested in your ideas.
>
> I need to make a strong case, so I'm exploring how to motivate my idea and I'm trying to discover any holes in it.  There's also a DMD bug I'd like to resolve before submitting a DIP.
>
> In general, my idea is to create a more limited `alias this`-like feature that will eliminate some of the "weird sh**" that comes with `alias this` and only keep the good stuff.  Whatever's left can be implemented with D's existing metaprogramming facilities.
>
> I believe it could be approved because it will significantly reduce the compiler's implementation and avoid a lot of bad interactions.  I think that would be appealing to Walter and others.
>
> If you want to discuss it you're welcome to contact me on Slack, Discord, or IRC under the handle JinShil and I'll give you all the details of what I have in mind.
>
> Mike

I do not know the url for the discord for the dlang community...

On Friday, 26 July 2019 at 13:07:25 UTC, 12345swordy wrote:

> I do not know the url for the discord for the dlang community...

https://discordapp.com/invite/YFujqFZ

On Friday, 26 July 2019 at 13:17:53 UTC, Mike Franklin wrote:
> On Friday, 26 July 2019 at 13:07:25 UTC, 12345swordy wrote:
>
>> I do not know the url for the discord for the dlang community...
>
> https://discordapp.com/invite/YFujqFZ

Joined.

On Thu, Jul 25, 2019 at 6:30 PM 12345swordy via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> Multi alias this is still not implemented. At this point of time I might as well  create a pr request that deprecate the alias this feature as it quite clearly that walter doesn't like it and hates implicit conversion for user types in general irregardless of design.
>
>
> -Alex

I don't personally like alias this except for very very specific use
cases. I don't like that we use of for implicit conversion, and I hate
that we use it for struct inheritance too.
I want to be able to mark constructors as @implicit or something
(inverse to C++ `explicit`). That would be my preferred expression of
implicit conversion.

On Friday, 26 July 2019 at 21:37:33 UTC, Manu wrote:
>
> I don't personally like alias this except for very very specific use
> cases. I don't like that we use of for implicit conversion, and I hate
> that we use it for struct inheritance too.

Completely agree.

I think struct inheritance (with no virtual dispatch) may be good for D. Has no one ever tried a DIP?

Allowing inheritance or alias this to be multiple is a separate debate; I tend to think there's no sane use case. As is (but related) allowing structs to implement interfaces (as in C# or Go? And without violating their value semantics).

On Saturday, 27 July 2019 at 04:15:38 UTC, XavierAP wrote:

> I think struct inheritance (with no virtual dispatch) may be good for D. Has no one ever tried a DIP?

I'm formulating one, but I haven't gotten very far yet.  Others have also mentioned interest.  Walter is quite opposed to implicit casting (https://github.com/dlang/dmd/pull/10161) so I was thinking of a different strategy that would use keep the implicit casting feature of `alias this` but defer the forwarding to members to D's metaprogramming facilities.

> Allowing inheritance or alias this to be multiple is a separate debate; I tend to think there's no sane use case. As is (but related) allowing structs to implement interfaces (as in C# or Go? And without violating their value semantics).

I think something like this should work:

struct IStream
{
    string read() { return ""; }
}

struct OStream
{
    void write(string s) { };
}

struct IOStream
{
    IStream i;
    OStream o;

    // Generating the following functions can be automated with D's awesome
    // metaprogramming facilities
    string read() { return i.read(); }
    void write(string s) { o.write(s); }

    // But how do we implicitly convert from `IOStream` to `IStream` or
    // `OStream` without `alias this`, `opImplicitCast` or some other?
    alias i this;
    alias o this; // mulitple `alias this` currently not implemented, so
                  // this doesn't work
}

extern string source(ref IStream i);
extern void sink(ref OStream o);

void main()
{
    IOStream io;

    source(io); // Won't work without some kind of implicit casting
    sink(io);   // Won't work without some kind of implicit casting
}

Mike