[Issue 17336] Implicit type conversion of size_t.init to int causes standard type compatibility test to break

[via Digitalmars-d-bugs]

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

--- Comment #4 from Adam D. Ruppe <destructionator at gmail.com> ---
> if A or B has @disabled this(), then .init may actually fail even if A+B actually compiles.  

That's not true, @disable this does not affect .init. .init WILL always
compile. In fact, it is legal to do `Foo foo = Foo.init;` when Foo has a
disabled default constructor; it still counts as explicit initialization.

But, .init is just a value. It doesn't represent a specific type, just the
default value of that type, and as such is subject to implicit casting.

That's why I think your test is buggy: it should be checking something more
like `canAdd!(Foo, size_t)`, not `typeof(some_foo + cast(size_t) 0)`; iow,
working entirely on types instead of on values.

I understand that's a bit of a pain to write, but it is more accurate. The
implementation of canAdd might be `__traits(compiles, () { A a = A.init; B b =
B.init; auto c = a + b; });` ... though that's a bit fragile too, since vrp may
someday cross statement boundaries and then the same thing comes up again. But
it'd work for now at least...

--