Bug 16572 – [Reg 2.072.0-b1] can't take inout delegate
Status
RESOLVED
Resolution
FIXED
Severity
regression
Priority
P1
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2016-10-02T10:43:00Z
Last change time
2016-11-04T09:05:32Z
Keywords
patch
Assigned to
nobody
Creator
turkeyman
Comments
Comment #0 by turkeyman — 2016-10-02T10:43:49Z
class Test
{
inout(int) f() inout { return 10; }
const(int) g() const { return 10; }
void t()
{
f(); // can call just fine with mutable 'this'
auto d = &this.f; // error : inout method Test.f is not callable using a mutable this
d();
auto e = &this.g; // no problem
e();
}
}
Other than the fact that I find this error message terribly misleading, I also don't think this situation is okay.
It's a terrible edge-case. Are we to say "unlike const, immutable; inout methods can not be captured as delegates"?
I guess the only reasonable solution here is to 'resolve' the inout-ness at the delegate capture?
Comment #1 by turkeyman — 2016-10-03T02:48:59Z
I have a project where I can't progress due to this issue :/
Comment #2 by dfj1esp02 — 2016-10-03T09:59:01Z
A small interaction between contravariance and inout here:
inout(A) f(inout B b) inout;
If you resolve the type as A delegate(B) you can't pass const(B) as argument.
Comment #3 by schveiguy — 2016-10-03T13:45:59Z
(In reply to anonymous4 from comment #2)
> A small interaction between contravariance and inout here:
> inout(A) f(inout B b) inout;
> If you resolve the type as A delegate(B) you can't pass const(B) as argument.
You wouldn't be able to take a valid delegate of this. Or at least an operational one.
The delegate type would have to be something like:
inout(A) delegate(inout B) inout=const
We don't have a way to express this.
As it stands, I think the delegate to this would have to be:
const(A) delegate(const(B) b) const
Comment #4 by dfj1esp02 — 2016-10-03T14:57:23Z
Oh, right, we have means to select an overload for delegate, we can reuse it here too.
Comment #5 by destructionator — 2016-10-06T03:11:56Z
Maybe marking it as a regression (like it is) will get it more attention.
Comment #7 by turkeyman — 2016-10-08T14:40:29Z
I would have thought 'blocker' would be taken seriously, but okay ;)
Comment #8 by issues.dlang — 2016-10-08T14:52:36Z
(In reply to Manu from comment #7)
> I would have thought 'blocker' would be taken seriously, but okay ;)
Maybe. But I'm not sure that there's generally a push to fix blockers like there is for regressions. Regressions definitely get searched for specifically on a semi-regular basis, and I don't know if anyone specifically looks for blockers. From what I've seen, regressions are usually take more seriously than any other kind of bug except maybe an ICE.
So, while in theory, blocker should definitely mean something significant, I don't know if it currently does in practice.
Comment #9 by code — 2016-10-08T21:15:32Z
(In reply to Jonathan M Davis from comment #6)
> Maybe marking it as a regression (like it is) will get it more attention.
Please don't hack our processes, but yes regressions like this should be filled as such.
We (and I particular) try to have zero new regressions per release.
It's one of our few prioritization strategies that still work, but it's fairly difficult for us to keep up with the current rate.
Also please file hardware and OS information accordingly, for obvious frontend bugs like this you know it all & all.
Switching to one of the crappy OSes (Windows, OSX, FreeBSD), requires quite some extra time, so I'm batching work for those.
Comment #10 by github-bugzilla — 2016-10-17T18:52:19Z