--- Comment #14 from timon.g...@gmx.ch 2011-11-10 13:58:05 PST ---
(In reply to comment #13)
> (In reply to comment #12)
> > (In reply to comment #11)
> > > You may be misunderstanding me. I agree this is a bug. I'll try to be
> > > clearer:
> > >
> > > 1. inout(const(T)) should resolve to const(T) or immutable(T) upon exit
> > > from
> > > inout scope. That it resolves to const(T) right now is a bug.
> > >
> > > 2. immutable(T) and inout(T) can legally implicitly cast to
> > > inout(const(T)).
> > > This is an enhancement.
> > Hm ok. I believe you are right for a possible interpretation of the language
> > spec. It states that nothing converts implicitly to inout, that immutable
> > and
> > inout convert to const but it does not make any mention of what converts to
> > inout const. Ergo it is contradictory and we are both right.
> > But 1. is not worth fixing if 2. is not implemented, therefore the bugfix
> > implies the enhancement. =)
> 2 can be forced with a cast. 1 cannot be worked around.
1. can be worked around fine in this particular case. Use inout(const(int))
for the return type.
It will give const(int) instead of const(int) for inout=mutable but that is
generally acceptable as those two types implicitly convert to each other.
It will not work for classes though. The workaround is to use structs and
implement the OO shenanigans oneself. Or to drop inout and use templates.
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------