The problem is that D does not have any formal semantics for its informal type system (this, of course, being a tautological statement).
The discovery of any "cool idiom" for disabling "pesky implicit conversion" is tantamount to engaging the same sorts of hacks that web programmers do with CSS (Cascading Style Sheets). Need I elaborate? People might scoff as they surely will but to even begin to understand formalism in data types this would be a good place to start ... W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes http://www.w3.org/TR/2009/WD-xmlschema11-2-20091203/ Editors (Version 1.1): David Peterson, invited expert (SGMLWorks!) <[email protected]> Shudi (Sandy) Gao 高殊镝, IBM <[email protected]> Ashok Malhotra, Oracle Corporation <[email protected]> C. M. Sperberg-McQueen, Black Mesa Technologies LLC <[email protected]> Henry S. Thompson, University of Edinburgh <[email protected]> Regards Justin Johansson Don Wrote: > I've found a pretty cool idiom for disabling pesky implicit conversion. > > This is a situation that I've encountered with BigInt; but I think it's > a general problem. > I have an "add integer" operation. Let's call it: > void add( x ), where x is a built-in integral type. > > If I define add(long x), everything works great -- it can be called with > x as a byte, ubyte, short, ushort, int, uint, or long. > Well, almost. Unfortunately, it doesn't work for ulong: add(ulong.max) > will either fail to compile, or get implicitly cast to add(-1)!! > > You can fix this by defining add(ulong x) as a special case. Now x can > be long or ulong, and it works. Great! > Problem is, now if x is an integer, the compiler complains that it's > ambiguous -- should it call the long or the ulong version? Bummer! > > You could solve that by creating int, uint, short, ushort,... functions. > Eight in total, but seven of them are identical. Massive source code > duplication. So use a template: > > void add(T)(T x) > { > // everything except ulong > } > > void add(T : ulong)(T x) > { > } > > Problem solved! Well, not quite. Now the source code duplication is > gone, but you still have template bloat: there are still 8 functions in > the executable. Then consider > void evenworse(x, y) > where both x AND y need special treatment if they are ulong. 8*8 = 64 > functions go into the executable, but only 4 of them are different! Ouch. > > If only there was a way to disable implicit conversions... > > void add()(long x) > { > assert(x == 7); > } > > void add(Tulong)(Tulong x) if ( is(Tulong == ulong) ) > { > assert(x == 6); > } > > void main() > { > add(7L); > add(6UL); > add(7); // Look ma, no conflicts! No bloat! > } > > Template constraints are seriously cool.
