Currently, DMD requires that the return type of a function that has inout-qualified parameters is itself qualified with inout. Removing this restriction would make the type system more expressive.
For example, the following function still requires code duplication to work for multiple differently qualified parameters:
void copy(int** tgt, int* src){ *tgt = src; }
void copy(immutable(int)** tgt, immutable(int)* src){ *tgt = src; }
void copy(const(int)** tgt, const(int)* src){ *tgt = src; }
With the lifted restriction, these three overloads can be merged:
void copy(inout(int)** tgt, inout(int)* src){ *tgt = src; }
Also see the newsgroup discussion on the topic:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=151839
Comment #1 by smjg — 2012-02-14T11:25:40Z
Another use case is to support foreach on a container of arbitrary constancy, by using
int opApply(int delegate(ref inout(T)) dg) inout;
Comment #2 by timon.gehr — 2012-02-14T11:44:47Z
That is an enhancement of what is suggested here. It is not very clear that inout should behave like that inside delegate/function pointer parameters. Maybe it is best if you open another enhancement request that discusses your design and its use cases in detail.
For example, what would be the meaning of the following declarations?
inout(int)[] delegate(inout(int)[] dg;
inout(int)[] foo(inout(int)[]delegate(inout(int)[] dg, inout(int)[] x){ ... }
Comment #3 by smjg — 2012-02-14T13:05:25Z
(In reply to comment #2)
> For example, what would be the meaning of the following declarations?
>
> inout(int)[] delegate(inout(int)[] dg;
> inout(int)[] foo(inout(int)[]delegate(inout(int)[] dg, inout(int)[] x){ ... }
Both of these would be syntax errors, because the brackets aren't matched.
But I see the ambiguity now. Does the inout status belong to the delegate itself or to the function of which it is a parameter?
If the signature of dg is invalid because it doesn't pass the inout status through, then in principle it could be taken to belong to the outer function. Which would be passing the inout status through to the delegate rather than as a return.
I'll think about it and continue the discussion on the newsgroup.
Stewart.
(In reply to comment #1)
> Another use case is to support foreach on a container of arbitrary constancy,
> by using
>
> int opApply(int delegate(ref inout(T)) dg) inout;
I think that the inout parameter contravariant (I've filed as issue 7542) is necessary due to enable such signatures.
Comment #6 by k.hara.pg — 2012-02-19T03:55:08Z
(In reply to comment #5)
> (In reply to comment #1)
> > Another use case is to support foreach on a container of arbitrary constancy,
> > by using
> >
> > int opApply(int delegate(ref inout(T)) dg) inout;
>
> I think that the inout parameter contravariant (I've filed as issue 7542) is
> necessary due to enable such signatures.
And I've posted issue 7543.
Comment #7 by smjg — 2012-02-19T06:37:31Z
(In reply to comment #3)
> (In reply to comment #2)
> > For example, what would be the meaning of the following declarations?
> >
> > inout(int)[] delegate(inout(int)[] dg;
> > inout(int)[] foo(inout(int)[]delegate(inout(int)[] dg, inout(int)[] x){ ... }
>
> Both of these would be syntax errors, because the brackets aren't matched.
>
> But I see the ambiguity now. Does the inout status belong to the delegate
> itself or to the function of which it is a parameter?
>
> If the signature of dg is invalid because it doesn't pass the inout status
> through, then in principle it could be taken to belong to the outer function.
> Which would be passing the inout status through to the delegate rather than as
> a return.
>
> I'll think about it and continue the discussion on the newsgroup.
digitalmars.D
"inout and function/delegate parameters"
On web interface:
http://forum.dlang.org/thread/[email protected]
Comment #8 by github-bugzilla — 2012-02-19T11:01:35Z