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


--- Comment #0 from timon.gehr@gmx.ch 2011-11-10 11:00:59 PST ---
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: -------

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


Steven Schveighoffer <schveiguy@yahoo.com> changed:

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


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

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



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

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


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

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



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

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



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

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


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

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


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

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



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

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



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

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



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