[Issue 16572] can't take inout delegate

[Issue 16572] [Reg 2.072.0-b1] can't take inout delegate

Oct 08, 2016

Martin Nowak

Oct 17, 2016

github-bugzilla@puremagic.com

Oct 17, 2016

github-bugzilla@puremagic.com

Oct 19, 2016

github-bugzilla@puremagic.com

Nov 04, 2016

github-bugzilla@puremagic.com

https://issues.dlang.org/show_bug.cgi?id=16572 Manu <turkeyman@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |blocker --- Comment #1 from Manu <turkeyman@gmail.com> --- I have a project where I can't progress due to this issue :/ --

https://issues.dlang.org/show_bug.cgi?id=16572 --- Comment #2 from anonymous4 <dfj1esp02@sneakemail.com> --- 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. --

https://issues.dlang.org/show_bug.cgi?id=16572 Steven Schveighoffer <schveiguy@yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |schveiguy@yahoo.com --- Comment #3 from Steven Schveighoffer <schveiguy@yahoo.com> --- (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 --

https://issues.dlang.org/show_bug.cgi?id=16572 --- Comment #4 from anonymous4 <dfj1esp02@sneakemail.com> --- Oh, right, we have means to select an overload for delegate, we can reuse it here too. --

https://issues.dlang.org/show_bug.cgi?id=16572 Adam D. Ruppe <destructionator@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |destructionator@gmail.com --- Comment #5 from Adam D. Ruppe <destructionator@gmail.com> --- See my comment on Github regarding a hacky fix, with the commit that introduced this bug and some logic behind my reasoning. I'm sure Walter (or someone who knows dmd well) can get a non-hack fix easily: https://github.com/dlang/dmd/commit/3c53a0fd9ed1b40f8dbeb75b4dfa11f6df5b3062#commitcomment-19312704 --

https://issues.dlang.org/show_bug.cgi?id=16572 --- Comment #8 from Jonathan M Davis <issues.dlang@jmdavisProg.com> --- (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. --

October 08, 2016

[Issue 16572] [Reg 2.072.0-b1] can't take inout delegate

Posted by Martin Nowak

Permalink

Martin Nowak

Permalink

https://issues.dlang.org/show_bug.cgi?id=16572

Martin Nowak <code@dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch
                 CC|                            |code@dawg.eu
           Hardware|x86_64                      |All
            Summary|can't take inout delegate   |[Reg 2.072.0-b1] can't take
                   |                            |inout delegate
                 OS|Windows                     |All

--- Comment #9 from Martin Nowak <code@dawg.eu> ---
(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.

--

Forums