Proof of concept - library AA

[Adam D. Ruppe via Digitalmars-d]

On Saturday, 30 May 2015 at 14:10:35 UTC, IgorStepanov wrote:
>     static Foo opImplicitConstructFrom(T)(T val) if(is(T : int))

I briefly mentioned this at the dconf and thinking about it a bit 
more, I think there's only two cases where we want implicit 
construction: function argument lists and function return values. 
(The syntax doesn't really matter, but I'd do it similar to C++ 
and just slap an @implicit on a regular constructor).


So:

struct Foo { @implicit this(typeof(null)) {} }

Foo test() {
    return null;
}

Right now, that return null would say "cannot implicitly convert 
null to Foo". But since it is on a return statement and we have 
an implicit constructor, it would automatically rewrite that to 
return Foo(null); and be happy with it.

Note that this does NOT change

Foo foo = null;

because that already works with a standard constructor today! 
Similarly, foo = null is handled with opAssign. So no change 
needed there.



Anyway, the trickier case is function calls:


void test(Foo) {}

test(null); // should do test(Foo(null));



How does that interact with operator overloading? (I'd note that 
C++ does this so we could always borrow their rules too.) My 
proposal would be that if something matches exactly without 
implicit conversion, use that. Otherwise, try the implicit 
construction and issue an error if more than one match.


This would work the same as arrays today:

void a(int[]) {}
void a(long[]) {}
void a(typeof(null)) {}

void main() { a(null); }


That compiles. Comment the third line though and get:

b.d(5): Error: b.a called with argument types (typeof(null)) 
matches both:
b.d(1):     b.a(int[] _param_0)
and:
b.d(2):     b.a(long[] _param_0)



So I think that's doable and shouldn't break any existing code as 
it is a new opt-in keyword. Just will have to watch for 
regression bugs...


But that'd take care of the null problem with library AAs.... and 
I could use it to make my var type all the more wild :P