Apparently three years ago it was we decided to ban alias this and opDispatch in the same class.
What are your thoughts on this now?
Is anyone depending on using alias this + opDispatch together like e.g. in https://github.com/dlang/phobos/pull/6596?

On Monday, June 25, 2018 23:13:12 Seb via Digitalmars-d wrote:
> Apparently three years ago it was we decided to ban alias this
> and opDispatch in the same class.
> What are your thoughts on this now?
> Is anyone depending on using alias this + opDispatch together
> like e.g. in https://github.com/dlang/phobos/pull/6596?

I think that that choice made a lot of sense, but regardless, I think that the only reason that the issue of whether having alias this and opDispatch on the same type has anything to do with Final is because if we make it illegal, then Final has to be fixed so that it only does one, whereas if we don't make it illegal, then presumably, we can leave Final as-is (assuming that having both opDispatch and alias this on Final doesn't result in subtle bugs, which it may).

Either way, conceptually, what Final is doing should use alias this. It's trying to implement head-const, and it really doesn't make sense to require an explicit cast to convert from head-const to fully const. That should work implicitly - which means using alias this. As far as I can tell, the only reason that opDispatch comes into the picture here at all is because Proxy was used in order to simplify Final's implementation. What Proxy is trying to do with sub-typing is fundamentally opposite of what Final is trying to do, since Proxy specifically does _not_ want implicit conversions, whereas Final does want them. If Final is fixed so that it doesn't reuse Proxy, then this whole problem goes away. Granted, that's a lot more work than what that PR currently does, but it's the right solution unless we're going to drop the idea of disallowing opDispatch and alias this on the same type, and given how alias this and opDispatch work, it seems highly risky in general to have them both be on the same type. It might actually work in some cases, but it sure seems like it's begging for subtle bugs.

- Jonathan M Davis

On Tuesday, 26 June 2018 at 00:56:13 UTC, Jonathan M Davis wrote:
> On Monday, June 25, 2018 23:13:12 Seb via Digitalmars-d wrote:
> - Jonathan M Davis

I've tried to fix this issue. If briefly there is one collision:

Final alias this should be r-value:

static struct S
{
    int i;
}

void test(ref S s) {}
auto val = Final!S(42);
assert (!__traits(compiles, test(val))); //val works as r-value

However should be able to mutate fields of val:

val.i = 24;
assert(val.i == 24); //should works

We may discard this case: for struct is value-type and head const should disable changing of fields. For example in C++ you can't declare instance of struct when you can not reassign instance, but can reassign a field.

On Monday, 25 June 2018 at 23:13:12 UTC, Seb wrote:
> Apparently three years ago it was we decided to ban alias this and opDispatch in the same class.
> What are your thoughts on this now?
> Is anyone depending on using alias this + opDispatch together like e.g. in https://github.com/dlang/phobos/pull/6596?

Yes! I at least depend on it: https://github.com/aliak00/optional/blob/master/source/optional/dispatcher.d And it's very deliberate as well, and not sure there's a workaround if this is banned. Or is there?

I went thought the DIP and I'm not sure I could exactly understand where the problems were - The first two-thirds seems to describe how alias this is used? Is that correct?

The sections Resolution Algorithm first describes how it "should" be resolved right? I didn't understand if that is different than the current resolution (is it?) and how though. Is the recursive alias this a problem or is that just a "btw, you can do this" kinda thing.

The Limitation section also says that opDispatch and alias this shouldn't be allowed, but why?

I think maybe the DIP seems to mix "will" and "should"? so it makes it hard to see what is the current behavior and what the behavior should be?

There is also no link to any discussions either - I see there was a forum discussion 4 years ago though, was that part of the DIP review process? - and going through it there were some questions for e.g. walter, timon, among others that I don't _think_ are answered in the dip.

Also, what would the work around be for code that relies on opDispatch and alias this? And shouldn't the PR take in to account the "Deprecation process" and deprecate it first before banning it?

Cheers,
- Ali

On Tuesday, 26 June 2018 at 03:07:08 UTC, aliak wrote:
> Also, what would the work around be for code that relies on opDispatch and alias this? And shouldn't the PR take in to account the "Deprecation process" and deprecate it first before banning it?
>
> Cheers,
> - Ali

s/shouldn't/will

Rephrased: will the usage of opDispatch with alias this be deprecated first :)

On Tuesday, June 26, 2018 03:17:37 aliak via Digitalmars-d wrote:
> On Tuesday, 26 June 2018 at 03:07:08 UTC, aliak wrote:
> > Also, what would the work around be for code that relies on opDispatch and alias this? And shouldn't the PR take in to account the "Deprecation process" and deprecate it first before banning it?
> >
> > Cheers,
> > - Ali
>
> s/shouldn't/will
>
> Rephrased: will the usage of opDispatch with alias this be deprecated first :)

Any such change would have to be done via deprecation, because it's a breaking change. Sometimes, breaking changes occur immediately due to bug fixes (though it's sometimes been argued that even breakage such as that should be minimized), but they should not occur due to a feature change unless the nature of the feature change absolutely could not be done via a deprecation, and it was deemed so critical that that breakage was worth it. There's no way that this falls in that camp.

So, if the change ends up being made, and it immediately breaks your code without there being any deprecation warning first, then someone wasn't doing their job properly, and you should report it as a regression.

- Jonathan M Davis

On 6/25/18 7:13 PM, Seb wrote:
> Apparently three years ago it was we decided to ban alias this and opDispatch in the same class.
> What are your thoughts on this now?
> Is anyone depending on using alias this + opDispatch together like e.g. in https://github.com/dlang/phobos/pull/6596?

My thoughts are that opDispatch should work with single or multiple alias this, and we should not deprecate the combination at all.

Why would opDispatch be treated any differently than the function that would be used with that name? Why are operator overloads not banned, they work the same way? The DIP mentions competing mechanisms of subtyping, but opDispatch isn't subtyping (it can be used to mimic another type, but doesn't allow the type to be considered as a base type).

-Steve