https://issues.dlang.org/show_bug.cgi?id=22159
--- Comment #3 from RazvanN <[email protected]> --- It's not a compiler bug. Here is where the error is emitted [1]. You can see that the druntime call is constructed and then semantic is tried. If there are any errors, the compiler simply assumes that the types are not compatible. This was introduced by kinke in [2] so that the user will not get errors pointing to druntime code. If in [2] we use `expressionSemantic` instead of `trySemantic` we would get an error stating that `core.object.opEquals` [3] is not @safe and cannot be @safe because it calls `Object.opEquals`. In fact, just comparing 2 classes with no user-defined opEquals - `assert (c == c)` - will issue an error in @safe code: "`@safe` function `D main` cannot call `@system` function `object.opEquals`". Therefore, the underlying issue is that `object.opEquals` is unsafe and cannot be made @safe because then any class is constrained to have a @safe opEquals. (I wonder if we can get around this by changing the attribute inheritance rule - point 6 in [4]) [1] https://github.com/dlang/dmd/blob/master/src/dmd/expressionsem.d#L11416 [2] https://github.com/dlang/dmd/pull/11212/files#diff-f0a120d764c7fab59bd3210b19fe685d2f106e4a1b9a33266804ae99dd3bbd4eR11135 [3] https://github.com/dlang/druntime/blob/master/src/object.d#L240 [4] https://dlang.org/spec/function.html#function-inheritance --
