Bug 20138 – is expression not evaluating correctly?

Check this out: alias X = shared inout int; pragma(msg, X, " ", is(X == shared U, U)); > shared(inout(int)) false I feel like that should print `true`, and U should be `inout(int)`...? This works: alias X = shared int; pragma(msg, X, " ", is(X == shared U, U)); > shared(int) true What's going on here?

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`

@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

@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

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[])

In my example above, it's weird that `shared` surrounds `int`, but `const` surrounds `int[]`... why are they applied at different levels?

(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.

Oh yeah; I confused myself when I didn't spot the placement of the parens initially. Ignore that post...

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?

(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.

I already have workarounds. I'm making a big report, because this seems to be a bug.

**Bug report.

dlang/phobos pull request #7147 "prepare for fix of issue 20138 ("is expression not evaluating correct…" was merged into master: - dc5e22944a048fb3a81f31875bcaa3c1adbb87ef by aG0aep6G: 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

dlang/dmd pull request #10317 "fix issue 20138 - is expression not evaluating correctly?" was merged into master: - 5b5219e7c2f5c9abe17b82cb38847a84d87517ca by aG0aep6G: 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`. - cc9b34c49edb1b3e012294c0fbbbcf605369c5eb by aG0aep6G: add changelog entry for issue 20138 https://github.com/dlang/dmd/pull/10317

*** Issue 20185 has been marked as a duplicate of this issue. ***