The combined type of immutable(T) and inout(T) should be inout(const(T)).
For example:
inout(const(int[])) foo(inout(int[]) x){
import std.random;
bool condition = cast(bool)uniform(0,2);
return condition ? x : new immutable(int[])(2);
}
(currently this code is still accepted because of issue 6912, but as soon as it is fixed this won't work anymore)
DMD 2.056 says that the combined type of immutable(T) and inout(T) is const(T), but that is losing information.
Comment #1 by schveiguy — 2011-11-10T11:13:29Z
I'm not seeing a good use case here.
Can't you just do:
return condition ? x : new inout(int[])(2);
Comment #2 by timon.gehr — 2011-11-10T11:16:41Z
(In reply to comment #1)
> I'm not seeing a good use case here.
>
> Can't you just do:
>
> return condition ? x : new inout(int[])(2);
Is this better?
immutable(int[]) bar(){
return new immutable(int[])(2);
}
inout(const(int[])) foo(inout(int[]) x){
import std.random;
bool condition = cast(bool)uniform(0,2);
return condition ? x : bar();
}
Comment #3 by schveiguy — 2011-11-10T11:36:41Z
So let my try to understand what inout(const(T)) actually means.
If inout resolves to mutable or const, this becomes const(T)
If inout resolves to immutable, this becomes immutable(T)
If inout resolves to inout (i.e. nested inout function), then it stays as inout(const(T))
Is this correct?
So what I think this boils down to is that inout(T) and immutable(T) should implicitly cast to inout(const(T)), given the rules above. It sure seems plausible.
I think the same should be extended to inout(const(T))* and inout(const(T))[]
I'd like Kenji to weigh in (added to CC). Does this affect the patch in bug 6912?
Comment #4 by timon.gehr — 2011-11-10T11:42:45Z
(In reply to comment #3)
> So let my try to understand what inout(const(T)) actually means.
>
> If inout resolves to mutable or const, this becomes const(T)
> If inout resolves to immutable, this becomes immutable(T)
> If inout resolves to inout (i.e. nested inout function), then it stays as
> inout(const(T))
>
> Is this correct?
Those were my thoughts, yes.
>
> So what I think this boils down to is that inout(T) and immutable(T) should
> implicitly cast to inout(const(T)), given the rules above. It sure seems
> plausible.
Yes, exactly. (That follows from inout(const(T)) being the combined type.)
>
> I think the same should be extended to inout(const(T))* and inout(const(T))[]
>
Good point.
> I'd like Kenji to weigh in (added to CC). Does this affect the patch in bug
> 6912?
Yes it does, the patch for 6912 currently claims inout(const(T)) is const(T).
Comment #5 by k.hara.pg — 2011-11-10T11:59:36Z
(In reply to comment #0)
> inout(const(int[])) foo(inout(int[]) x){
> import std.random;
> bool condition = cast(bool)uniform(0,2);
> return condition ? x : new immutable(int[])(2);
> }
>
> (currently this code is still accepted because of issue 6912, but as soon as it
> is fixed this won't work anymore)
I think that the reason why this code works is bug 6922, not bug 6912.
Because bug 6922 parses inout(const(int[])) as inout(int[]).
Comment #6 by k.hara.pg — 2011-11-10T12:22:18Z
I think this issue is an enhancement.
With current dmd implementation, the result type of an inout function has *always* four possibilities, they are mutable, const, and immutable, and inout.
The implementation of this enhancement will restrict the possibilities.
inout(const(T)) foo(...) { ... }
// can return only const(T), immutable(T), or inout(const(T)).
It seems to be usable a little, but I'm not seeing a use case of that.
Comment #7 by schveiguy — 2011-11-10T12:38:04Z
What it does is allow you to return data that is immutable, but is not part of the input, and still have it be immutable after inout is resolved.
The example given isn't quite compelling, because the data is always being created (even if hidden behind a secondary function).
However, this is a more solid use case:
immutable(int)[] n = [1,2,3];
inout(const(int))[] foo(inout(int)[] x){
import std.random;
bool condition = cast(bool)uniform(0,2);
return condition ? x : n;
}
Without this, this cannot be an inout function. It's signature would be:
const(int)[] foo(const(int)[] x)
Although this is legal, it loses specificity in the case where an immutable is passed in.
I'm not saying it's not an enhancement or that the benefit is huge, but it's definitely an improvement.
Comment #8 by timon.gehr — 2011-11-10T12:39:59Z
(In reply to comment #6)
> I think this issue is an enhancement.
I strongly disagree. What qualifies it as an enhancement for you?
>
> With current dmd implementation, the result type of an inout function has
> *always* four possibilities, they are mutable, const, and immutable, and inout.
>
> The implementation of this enhancement will restrict the possibilities.
>
> inout(const(T)) foo(...) { ... }
> // can return only const(T), immutable(T), or inout(const(T)).
>
> It seems to be usable a little, but I'm not seeing a use case of that.
I am not saying that this has an enormous priority, but it definitely is a bug in my eyes. The inout qualifier has failed if there are cases where it could work but does not.
Comment #9 by schveiguy — 2011-11-10T12:50:44Z
(In reply to comment #8)
> (In reply to comment #6)
> > I think this issue is an enhancement.
>
> I strongly disagree. What qualifies it as an enhancement for you?
It *is* an enhancement, because the common type can just as easily be const, and the code is still valid. You are asking for an incremental change to how inout works.
> I am not saying that this has an enormous priority, but it definitely is a bug
> in my eyes. The inout qualifier has failed if there are cases where it could
> work but does not.
inout's primary focus is transferring the type modifier from the arguments to the return type. Merging it with a possible external immutable type is secondary.
I think inout(const(T)) should resolve as we've discussed. The enhancement is that immutable(T) and inout(T) should be implicitly castable to inout(const(T)). Those aspects were not envisioned when the feature was created, so it works as designed (provided the resolution of inout(const(T)) is fixed).
Comment #10 by timon.gehr — 2011-11-10T13:12:29Z
(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #6)
> > > I think this issue is an enhancement.
> >
> > I strongly disagree. What qualifies it as an enhancement for you?
>
> It *is* an enhancement, because the common type can just as easily be const,
> and the code is still valid. You are asking for an incremental change to how
> inout works.
>
> > I am not saying that this has an enormous priority, but it definitely is a bug
> > in my eyes. The inout qualifier has failed if there are cases where it could
> > work but does not.
>
> inout's primary focus is transferring the type modifier from the arguments to
> the return type. Merging it with a possible external immutable type is
> secondary.
>
> I think inout(const(T)) should resolve as we've discussed. The enhancement is
> that immutable(T) and inout(T) should be implicitly castable to
> inout(const(T)).
See specification of inout:
http://d-programming-language.org/function.html
"The inout forms a wildcard that stands in for any of mutable, const or immutable. When the function is called, the inout of the return type is changed to whatever the mutable, const, or immutable status of the argument type to the parameter inout was."
If inout(const(T)) is parsed as const(T) then the inout does not form a wildcard that can stand for immutable. Contradiction with the language specification. That is a bug.
(The specification does not mention any odd special cases!)
> Those aspects were not envisioned when the feature was
> created, so it works as designed (provided the resolution of inout(const(T)) > is fixed).
s/created/implemented/g
You are arguing that DMD is sorta the language specification. It is not. It is a buggy implementation of the language specification and cannot be relied upon.
When inout was created there was only the spec. The implementation does not live up to the spec. It does not matter whether or not the issue was known while writing the spec for deciding whether or not a particular implementation implements the specification.
As an analogy, consider this function:
Tour TSP(Graph g);
It's specification says: This function solves the traveling salesman problem in polynomial time.
Now comes the poor guy who implements the function:
Tour TSP(Graph g){ /* approximate the optimal solution */ }
The guy who wrote the specification did not think about the fact that solving TSP in polynomial time is hard. Does that make the approximate solution correct? It does not.
Do you agree?
Comment #11 by schveiguy — 2011-11-10T13:22:28Z
(In reply to comment #10)
> (In reply to comment #9)
> > inout's primary focus is transferring the type modifier from the arguments to
> > the return type. Merging it with a possible external immutable type is
> > secondary.
> >
> > I think inout(const(T)) should resolve as we've discussed. The enhancement is
> > that immutable(T) and inout(T) should be implicitly castable to
> > inout(const(T)).
>
> See specification of inout:
> http://d-programming-language.org/function.html
>
> "The inout forms a wildcard that stands in for any of mutable, const or
> immutable. When the function is called, the inout of the return type is changed
> to whatever the mutable, const, or immutable status of the argument type to the
> parameter inout was."
>
> If inout(const(T)) is parsed as const(T) then the inout does not form a
> wildcard that can stand for immutable. Contradiction with the language
> specification. That is a bug.
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.
Comment #12 by timon.gehr — 2011-11-10T13:33:33Z
(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #9)
> > > inout's primary focus is transferring the type modifier from the arguments to
> > > the return type. Merging it with a possible external immutable type is
> > > secondary.
> > >
> > > I think inout(const(T)) should resolve as we've discussed. The enhancement is
> > > that immutable(T) and inout(T) should be implicitly castable to
> > > inout(const(T)).
> >
> > See specification of inout:
> > http://d-programming-language.org/function.html
> >
> > "The inout forms a wildcard that stands in for any of mutable, const or
> > immutable. When the function is called, the inout of the return type is changed
> > to whatever the mutable, const, or immutable status of the argument type to the
> > parameter inout was."
> >
> > If inout(const(T)) is parsed as const(T) then the inout does not form a
> > wildcard that can stand for immutable. Contradiction with the language
> > specification. That is a bug.
>
> 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. =)
Comment #13 by schveiguy — 2011-11-10T13:41:52Z
(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.
Comment #14 by timon.gehr — 2011-11-10T13:58:05Z
(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.
Comment #15 by k.hara.pg — 2011-12-04T21:37:31Z
While implementing this enhancement, I've found an issue.
Following code now can compile, but introducing inout(const(T)) breaks it.
bool hasDrive(C)(in C[] path)
{
return true;
}
inout(C)[] stripDrive(C)(inout(C)[] path)
{
if (hasDrive(path)) // Line 7
return path[2 .. $];
return path;
}
void main()
{
assert(stripDrive(`c:\`) == `\`);
}
-- error with my local patched dmd
test.d(1): Error: inout on parameter means inout must be on return type as well (if from D1 code, replace with 'ref')
test.d(1): Error: variable test.hasDrive!(inout(char)).hasDrive.path inout variables can only be declared inside inout functions
test.d(7): Error: template instance test.hasDrive!(inout(char)) error instantiating
test.d(13): instantiated from here: stripDrive!(char)
test.d(13): Error: template instance test.stripDrive!(char) error instantiating
In IFTI with hasDrive(path), C is deduced as inout(char), then a parameter 'path' is typed as 'in inout(char)', it is translated as inout(const(char)).
Give me opinions, please.
Comment #16 by timon.gehr — 2011-12-05T03:13:43Z
Thank you for taking the time to implement this!
I think the issue you ran into is issue 6809.
Once issue 6809 is fixed, the code should compile again.
in inout(C) -> inout(const(C)) -> (issue 6809) -> const(const(C)) -> const(C).
Comment #17 by schveiguy — 2011-12-05T07:02:52Z
I need to re-reason this enhancement through in order to give an informed opinion, it's complex :)
But issue 6809 needs to be fixed regardless. What if we fix that, then see how it affects this problem?
Comment #18 by k.hara.pg — 2013-12-09T03:22:32Z
To avoid std.traits breaking, issue 11711 enhancement is necessary.