[Issue 6930] combined type of immutable(T) and inout(T) should be inout(const(T))
https://d.puremagic.com/issues/show_bug.cgi?id=6930 --- Comment #20 from github-bugzi...@puremagic.com 2013-12-21 12:56:19 PST --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/c895ff7f1f1df0892c0c56a43c256b86592396f0 Clean up inout deduction - Rename `Type::wildConvTo` to `deduceWild` - Use `wildmatch` for sum of arguments match level, and use `wm` for one parameter match level. - Extract current workarounds for issue 6930 https://github.com/D-Programming-Language/dmd/commit/2c0ead859f208d80190d4e634b5a0737d4b64645 fix Issue 6930 - combined type of immutable(T) and inout(T) should be inout(const(T)) https://github.com/D-Programming-Language/dmd/commit/6f4866b5b07094861c55f20165496019683242ef Merge pull request #2992 from 9rnsr/fix6930 [enh] Issue 6930 - combined type of immutable(T) and inout(T) should be inout(const(T)) -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6930] combined type of immutable(T) and inout(T) should be inout(const(T))
https://d.puremagic.com/issues/show_bug.cgi?id=6930 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6930] combined type of immutable(T) and inout(T) should be inout(const(T))
https://d.puremagic.com/issues/show_bug.cgi?id=6930 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #19 from Kenji Hara k.hara...@gmail.com 2013-12-19 20:07:03 PST --- https://github.com/D-Programming-Language/dmd/pull/2992 https://github.com/D-Programming-Language/phobos/pull/1794 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6930] combined type of immutable(T) and inout(T) should be inout(const(T))
https://d.puremagic.com/issues/show_bug.cgi?id=6930 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Depends on||11711 --- Comment #18 from Kenji Hara k.hara...@gmail.com 2013-12-09 03:22:32 PST --- To avoid std.traits breaking, issue 11711 enhancement is necessary. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6930] combined type of immutable(T) and inout(T) should be inout(const(T))
http://d.puremagic.com/issues/show_bug.cgi?id=6930 --- Comment #16 from timon.g...@gmx.ch 2011-12-05 03:13:43 PST --- 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). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6930] combined type of immutable(T) and inout(T) should be inout(const(T))
http://d.puremagic.com/issues/show_bug.cgi?id=6930 --- Comment #17 from Steven Schveighoffer schvei...@yahoo.com 2011-12-05 07:02:52 PST --- 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? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6930] combined type of immutable(T) and inout(T) should be inout(const(T))
http://d.puremagic.com/issues/show_bug.cgi?id=6930
--- Comment #15 from Kenji Hara k.hara...@gmail.com 2011-12-04 21:37:31 PST
---
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.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6930] combined type of immutable(T) and inout(T) should be inout(const(T))
http://d.puremagic.com/issues/show_bug.cgi?id=6930 Steven Schveighoffer schvei...@yahoo.com changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #1 from Steven Schveighoffer schvei...@yahoo.com 2011-11-10 11:13:29 PST --- I'm not seeing a good use case here. Can't you just do: return condition ? x : new inout(int[])(2); -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6930] combined type of immutable(T) and inout(T) should be inout(const(T))
http://d.puremagic.com/issues/show_bug.cgi?id=6930
--- Comment #2 from timon.g...@gmx.ch 2011-11-10 11:16:41 PST ---
(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();
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6930] combined type of immutable(T) and inout(T) should be inout(const(T))
http://d.puremagic.com/issues/show_bug.cgi?id=6930 Steven Schveighoffer schvei...@yahoo.com changed: What|Removed |Added CC||k.hara...@gmail.com --- Comment #3 from Steven Schveighoffer schvei...@yahoo.com 2011-11-10 11:36:41 PST --- 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? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6930] combined type of immutable(T) and inout(T) should be inout(const(T))
http://d.puremagic.com/issues/show_bug.cgi?id=6930 --- Comment #4 from timon.g...@gmx.ch 2011-11-10 11:42:45 PST --- (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). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6930] combined type of immutable(T) and inout(T) should be inout(const(T))
http://d.puremagic.com/issues/show_bug.cgi?id=6930
--- Comment #5 from Kenji Hara k.hara...@gmail.com 2011-11-10 11:59:36 PST ---
(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[]).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6930] combined type of immutable(T) and inout(T) should be inout(const(T))
http://d.puremagic.com/issues/show_bug.cgi?id=6930
Kenji Hara k.hara...@gmail.com changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #6 from Kenji Hara k.hara...@gmail.com 2011-11-10 12:22:18 PST ---
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.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6930] combined type of immutable(T) and inout(T) should be inout(const(T))
http://d.puremagic.com/issues/show_bug.cgi?id=6930
--- Comment #7 from Steven Schveighoffer schvei...@yahoo.com 2011-11-10
12:38:04 PST ---
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.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6930] combined type of immutable(T) and inout(T) should be inout(const(T))
http://d.puremagic.com/issues/show_bug.cgi?id=6930
--- Comment #8 from timon.g...@gmx.ch 2011-11-10 12:39:59 PST ---
(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.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6930] combined type of immutable(T) and inout(T) should be inout(const(T))
http://d.puremagic.com/issues/show_bug.cgi?id=6930 --- Comment #9 from Steven Schveighoffer schvei...@yahoo.com 2011-11-10 12:50:44 PST --- (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). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6930] combined type of immutable(T) and inout(T) should be inout(const(T))
http://d.puremagic.com/issues/show_bug.cgi?id=6930
--- Comment #10 from timon.g...@gmx.ch 2011-11-10 13:12:29 PST ---
(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?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6930] combined type of immutable(T) and inout(T) should be inout(const(T))
http://d.puremagic.com/issues/show_bug.cgi?id=6930 --- Comment #11 from Steven Schveighoffer schvei...@yahoo.com 2011-11-10 13:22:28 PST --- (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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6930] combined type of immutable(T) and inout(T) should be inout(const(T))
http://d.puremagic.com/issues/show_bug.cgi?id=6930 --- Comment #12 from timon.g...@gmx.ch 2011-11-10 13:33:33 PST --- (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. =) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6930] combined type of immutable(T) and inout(T) should be inout(const(T))
http://d.puremagic.com/issues/show_bug.cgi?id=6930 --- Comment #13 from Steven Schveighoffer schvei...@yahoo.com 2011-11-10 13:41:52 PST --- (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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6930] combined type of immutable(T) and inout(T) should be inout(const(T))
http://d.puremagic.com/issues/show_bug.cgi?id=6930 --- 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: ---
