https://issues.dlang.org/show_bug.cgi?id=19126

--- Comment #11 from Steven Schveighoffer <schveiguy@yahoo.com> ---
(In reply to Ali Ak from comment #10)
> Ahhh this inout just hurts my head. So is fixing inout on return a much bigger bug than the more simple "don't remove inout from a parameter if the return value has inout"?

I'm thinking now that actually, even removing the restriction of saying inout can't be on the return unless it's on the parameter (i.e. issue 13006) doesn't fix the code exactly, but it will move the error to where it makes more sense. In other words, it will error on the line where you try to pass in an immutable(T) to an inout W!T. Then the error is more obvious.

So you are right, it's not as simple as that. My analysis in comment 2 is not correct.

> 
> Currently you can do this and then things behave consistently. Fixes this problem but does't solve the "allowing inout on return" problem.
> 
> auto wrap0(T)(inout(T) t) {
>     static if (is(T == immutable)) {
>     	return immutable W!T();
>     } else {
>         return inout W!T();
>     }
> }

I'm still finding trouble understanding why you want to specify immutable explicitly as the T value. Why not just mutable T? Then you don't need that machinery at all.

> When T is an immutable it seems like the compiler should be doing this by
> itself. If it decides to "replace" inout(immutable) with just immutable,
> then it should replace inout everywhere with immutable. SO why doesn't
> inout(W!(immutable int)) become immutable(T!int)? That would also make this
> error go away right?

But that's not what you specified. inout(SomeTemplate!(immutable(T))) cannot be
replaced in all cases with immmutable(SomeTemplate!T). In this case, it would
be OK, but the compiler would have to do a lot to prove that.

> Maybe the compiler shouldn't be reducing inout in the first place? It is supposed to be (IIUC) qualifiers in => qualifiers out right? So why does it remove it before the it "lands" somewhere? This makes no sense regardless of immutable being the strongest qualifier. The purposes of inout and immutable seem orthogonal. It's not a mutability qualifier, it's a "transport of mutability information" qualifier right?

Its behavior is the least common denominator of all 3 mutability parameters. The things you can do with inout are all the things you could do with a mutable, immutable, or const version, and nothing more.

However, any qualifier that is added on top of immutable is immutable, so the compiler is stripping away inout to simplify things.

But it can only do this on types that are fully immutable. In the case of the struct, only the member is immutable, it's not immutable on the whole struct.

Again, the best fix for this is simply not to instantiate with immutable(T). You can achieve everything without it.

--

https://issues.dlang.org/show_bug.cgi?id=19126

--- Comment #12 from Ali Ak <ali.akhtarzada@gmail.com> ---
(In reply to Steven Schveighoffer from comment #11)
> 
> I'm still finding trouble understanding why you want to specify immutable explicitly as the T value. Why not just mutable T? Then you don't need that machinery at all.

It's not that I want to or don't want to, it's that I think it should work consistently.

> 
> > When T is an immutable it seems like the compiler should be doing this by
> > itself. If it decides to "replace" inout(immutable) with just immutable,
> > then it should replace inout everywhere with immutable. SO why doesn't
> > inout(W!(immutable int)) become immutable(T!int)? That would also make this
> > error go away right?
> 
> But that's not what you specified. inout(SomeTemplate!(immutable(T))) cannot
> be replaced in all cases with immmutable(SomeTemplate!T). In this case, it
> would be OK, but the compiler would have to do a lot to prove that.

Ah true.

> 
> > Maybe the compiler shouldn't be reducing inout in the first place? It is supposed to be (IIUC) qualifiers in => qualifiers out right? So why does it remove it before the it "lands" somewhere? This makes no sense regardless of immutable being the strongest qualifier. The purposes of inout and immutable seem orthogonal. It's not a mutability qualifier, it's a "transport of mutability information" qualifier right?
> 
> Its behavior is the least common denominator of all 3 mutability parameters. The things you can do with inout are all the things you could do with a mutable, immutable, or const version, and nothing more.

Yes, so it feels weird that since it acts as a common denominator, the compiler throws it away before it's done acting O_o

> 
> However, any qualifier that is added on top of immutable is immutable, so the compiler is stripping away inout to simplify things.

Ya I understand that's what's happening now. It just sounds like the compiler is doing the wrong thing by removing inout in this case. Because it leads to a compiler error with code that should "obviously" work.

It would be nice to just find this simplification line (if it even is a line) in the compiler and see if just making it not "simplify" removal of inout (i guess any inner inouts can be removed) will just keep everything working including this case. I'm just not familiar enough with dmd to be able to give this a try just yet.


> 
> But it can only do this on types that are fully immutable. In the case of the struct, only the member is immutable, it's not immutable on the whole struct.
> 
> Again, the best fix for this is simply not to instantiate with immutable(T). You can achieve everything without it.

Well I guess that's more a "it works if you do it like this" solution than a fix :) D supports explicit template instantiation as a feature of the language no? But it's not "working" in this case - T can be given any qualified type, inout acts as a common denominator => seems like this should work.

--

https://issues.dlang.org/show_bug.cgi?id=19126

Ali Ak <ali.akhtarzada@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|diagnostic                  |

--- Comment #13 from Ali Ak <ali.akhtarzada@gmail.com> ---
Ran in to this again why writing a library. Removing diagnostic because I don't see why the compiler can't make this edge case work, and marking it as diagnostic seems to miss the point of the issue.

void f(immutable int) {}
f(3) // works
wrap!(const int)(3) // works
so wrap!(immutable int)(3) should work.

and it does with a hack so why not support it properly?

--

https://issues.dlang.org/show_bug.cgi?id=19126

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P3

--

https://issues.dlang.org/show_bug.cgi?id=19126

--- Comment #14 from dlangBugzillaToGithub <robert.schadek@posteo.de> ---
THIS ISSUE HAS BEEN MOVED TO GITHUB

https://github.com/dlang/dmd/issues/19470

DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB

--