www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - opDispatch and alias this

reply Seb <seb wilzba.ch> writes:
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?
Jun 25 2018
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Jun 25 2018
parent IgorStepanov <is kalabi.ru> writes:
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.
Jun 25 2018
prev sibling next sibling parent reply aliak <something something.com> writes:
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
Jun 25 2018
parent reply aliak <something something.com> writes:
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 :)
Jun 25 2018
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Jun 25 2018
prev sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Jun 26 2018