[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