[Issue 17336] Implicit type conversion of size_t.init to int causes standard type compatibility test to break
via Digitalmars-d-bugs
digitalmars-d-bugs at puremagic.com
Thu Apr 20 12:54:53 PDT 2017
https://issues.dlang.org/show_bug.cgi?id=17336
--- Comment #2 from hsteoh at quickfur.ath.cx ---
On -m32, the test does exactly what it should: opBinary(int) *can* take size_t
when size_t is 32-bit.
The problem here is that T.init is the standard way to obtain an instance of T
in generic code, because you don't know what T is and that's the only way to
obtain an instance of T for type-compatibility testing purposes. You certainly
cannot expect .max to exist for generic T, after all.
The code given here uses size_t.init explicitly because it was reduced from
generic code. The generic form of the code looks something like this:
-------
static if (is(typeof(A.init + B.init) : A)) { ... }
-------
There is no way you can know, in generic code, that B.init may magically
implicitly convert to some other type C that passes the check, yet later on
when you try to add an instance of B to A, it fails to compile.
Or perhaps this is an argument for not using .init in generic code at all,
since with the recent language changes it has basically become worthless --
another problem is that if A or B has @disabled this(), then .init may actually
fail even if A+B actually compiles. Perhaps I should just accept that every
time I need to do a type compatibility check I should write this instead:
-------
static if (is(typeof((A a, B b) => a + b) : A)) { ... }
-------
--
More information about the Digitalmars-d-bugs
mailing list