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

--- Comment #1 from Manu <turkeyman@gmail.com> ---
  alias X = shared int;
  pragma(msg, X, "  ", is(X == shared U, U), "  ", U));

> shared(int)  true   int


  alias X = shared inout int;
  pragma(msg, X, "  ", is(X == shared U, U), "  ", U));

> shared(inout(int))   false   Error: undefined identifier `U`

--

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

Dlang Bot <dlang-bot@dlang.rocks> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull

--- Comment #2 from Dlang Bot <dlang-bot@dlang.rocks> ---
@aG0aep6G created dlang/dmd pull request #10317 "fix issue 20138 - is expression not evaluating correctly?" fixing this issue:

- fix issue 20138 - is expression not evaluating correctly?

  When passing a `shared const T` into a `shared U` parameter, then no const
  conversion is needed to infer `U` as `const int`. Same with `inout int` and
  `inout const int`.

https://github.com/dlang/dmd/pull/10317

--

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

ag0aep6g <ag0aep6g@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ag0aep6g@gmail.com

--

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

--- Comment #3 from Dlang Bot <dlang-bot@dlang.rocks> ---
@aG0aep6G created dlang/phobos pull request #7147 "prepare for fix of issue 20138 ("is expression not evaluating correct…" mentioning this issue:

- prepare for fix of issue 20138 ("is expression not evaluating correctly?")

  With issue 20138 fixed, `const U` and `shared U` do match `const shared T`,
  and they leave the other qualifier intact. So `const shared U` must be
  attempted first if we want to strip both qualifiers.

https://github.com/dlang/phobos/pull/7147

--

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

--- Comment #4 from Manu <turkeyman@gmail.com> ---
Is this another construction of the same issue, or is it a similar but unrelated issue?

  T fun(T)(shared(T) a)
  {
      return a;
  }
  shared const int[] x;
  pragma(msg, typeof(fun(x)));

> const(shared(int)[])    !!!

`T` should be typeof(x) but with shared peeled away: const(int[])

--

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

--- Comment #5 from Manu <turkeyman@gmail.com> ---
In my example above, it's weird that `shared` surrounds `int`, but `const` surrounds `int[]`... why are they applied at different levels?

--

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

--- Comment #6 from ag0aep6g <ag0aep6g@gmail.com> ---
(In reply to Manu from comment #4)
>   T fun(T)(shared(T) a)
>   {
>       return a;
>   }
>   shared const int[] x;
>   pragma(msg, typeof(fun(x)));
> 
> > const(shared(int)[])    !!!
> 
> `T` should be typeof(x) but with shared peeled away: const(int[])

It is typeof(x) but with shared peeled away (from the head of the type).

typeof(x) is: shared(const(E[])) where E is shared(const(int)).
Peel shared away from typeof(x): const(E[]).
Expand E: const(shared(const(int))[]).
Simplify: const(shared(int)[]).

(In reply to Manu from comment #5)
> In my example above, it's weird that `shared` surrounds `int`, but `const` surrounds `int[]`... why are they applied at different levels?

`shared` is in the signature, `const` isn't.

If you change fun's parameter to `shared(const(T)) a`, the return type becomes
`shared(const(int))[]` as expected.

--

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

--- Comment #7 from Manu <turkeyman@gmail.com> ---
Oh yeah; I confused myself when I didn't spot the placement of the parens
initially.
Ignore that post...

--

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

Simen Kjaeraas <simen.kjaras@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |simen.kjaras@gmail.com

--- Comment #8 from Simen Kjaeraas <simen.kjaras@gmail.com> ---
is(shared const int : shared U, U) does evaluate to true, and U is const int. Can you elaborate on why that's not good enough?

--

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

--- Comment #9 from ag0aep6g <ag0aep6g@gmail.com> ---
(In reply to Simen Kjaeraas from comment #8)
> is(shared const int : shared U, U) does evaluate to true, and U is const int. Can you elaborate on why that's not good enough?

That seems like a viable workaround, hinging on the fact that `is(int : shared
U, U)` is false even though there are possible values for `U` that would pass
(e.g., `is(int : shared int)` is true).

But it doesn't change that the result of `==` is wrong.

--