http://d.puremagic.com/issues/show_bug.cgi?id=6930



--- Comment #10 from timon.gehr@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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6930



--- Comment #11 from Steven Schveighoffer <schveiguy@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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6930



--- Comment #12 from timon.gehr@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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6930



--- Comment #13 from Steven Schveighoffer <schveiguy@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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6930



--- Comment #14 from timon.gehr@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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6930



--- Comment #15 from Kenji Hara <k.hara.pg@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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6930



--- Comment #16 from timon.gehr@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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6930



--- Comment #17 from Steven Schveighoffer <schveiguy@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: -------