Multiple alias this, what's the hold up? (page 6)

On Monday, 17 June 2019 at 16:13:07 UTC, rikki cattermole wrote: > On 18/06/2019 3:58 AM, user1234 wrote: >> On Monday, 17 June 2019 at 13:48:45 UTC, Mike Franklin wrote: >>> I think if we had an `opAssignRight` feature (with friends) we could move the entire implementation of `alias this` to the library. [...] >>> Mike >> >> At first glance opAssignRight is a really **brilliant** idea 👍. >> Why do you think that variants would be required ? i += s would work with the single op overload. Maybe it would more be something like >> >> T opExtractRight(T){}, with T saying what type is involved in the operation >> >> int i = s rewritten as int i = s.opExtractRight!int(); >> i += s rewritten as i += s.opExtractRight!int(); > > Oh I like this. > This way it doesn't fight the other operator overloads and can be used (with them) only if they fail as-is. Hi. I've decided to give a try [1]. As expected it's reasonably simple but I haven't tested it extensively. Actually I'm more interested by a second form that allows to implicitly convert a parameter to a custom type (called opImplicitConvL). [1] : https://github.com/Basile-z/dmd/pull/2 Now as said on IRC, the harder is to write a solid proposal.

September 06

Implicit opCast in place of alias this ?

Posted by user1234
in reply to user1234

Permalink

user1234

Posted in reply to user1234

Permalink

On Monday, 17 June 2019 at 16:18:55 UTC, user1234 wrote:

On Monday, 17 June 2019 at 16:13:07 UTC, rikki cattermole wrote:

On 18/06/2019 3:58 AM, user1234 wrote:

On Monday, 17 June 2019 at 13:48:45 UTC, Mike Franklin wrote:

I think if we had an opAssignRight feature (with friends) we could move the entire implementation of alias this to the library. [...]
Mike

At first glance opAssignRight is a really brilliant idea 👍.
Why do you think that variants would be required ? i += s would work with the single op overload. Maybe it would more be something like

T opExtractRight(T){}, with T saying what type is involved in the operation

int i = s rewritten as int i = s.opExtractRight!int();
i += s rewritten as i += s.opExtractRight!int();

Oh I like this.
This way it doesn't fight the other operator overloads and can be used (with them) only if they fail as-is.

It looks very much like "opCast" actually and a better named is "opImplicitConv"
because right now the error message for Mike's little example says "cannot impliclty convert...".

I've implemented that yesteday and the first problem I encountered was "wait that should work directly". So the problem you have with that solution is that the operator overload that gives the data that is controlled is rarely needed. Most of the time you have to overload each every fucking operators.

So in the end you end up with the exact same thing as alias this.

Simple exmple

a = b;

Here in this case a compiler does not try to find the mutual common type of a and b. Instead it just tries to see if b type can convert to the a one.

With alias this, eventually the compiler has to try if a can yield a lvalue of b type.

In the end that's the exact same problem. That adds complexity for a special case.
For every each case where implicit conv is not tried, you also have to try alias this or the alternative opImplicitConvRight.

It's the same thing.

Forums