An idiom for disabling implicit conversions

[Justin Johansson]

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!) <davep at iit.edu>
    Shudi (Sandy) Gao &#39640;&#27530;&#38237;, IBM <sandygao at ca.ibm.com>
    Ashok Malhotra, Oracle Corporation <ashokmalhotra at alum.mit.edu>
    C. M. Sperberg-McQueen, Black Mesa Technologies LLC <cmsmcq at blackmesatech.com>
    Henry S. Thompson, University of Edinburgh <ht at inf.ed.ac.uk>

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.