www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 6930] New: combined type of immutable(T) and inout(T) should be inout(const(T))

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6930

           Summary: combined type of immutable(T) and inout(T) should be
                    inout(const(T))
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: timon.gehr gmx.ch



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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 10 2011
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6930


Steven Schveighoffer <schveiguy yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy yahoo.com



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: -------
Nov 10 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6930






 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: -------
Nov 10 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6930


Steven Schveighoffer <schveiguy yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |k.hara.pg gmail.com



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: -------
Nov 10 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6930






 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: -------
Nov 10 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6930






 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: -------
Nov 10 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6930


Kenji Hara <k.hara.pg gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement



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: -------
Nov 10 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6930




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: -------
Nov 10 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6930






 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: -------
Nov 10 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6930




12:50:44 PST ---




 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: -------
Nov 10 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6930










 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: -------
Nov 10 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6930




13:22:28 PST ---




 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: -------
Nov 10 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6930










 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: -------
Nov 10 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6930




13:41:52 PST ---




 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: -------
Nov 10 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6930










 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: -------
Nov 10 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6930




---
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: -------
Dec 04 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6930




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: -------
Dec 05 2011
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6930




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: -------
Dec 05 2011