Proof of concept - library AA

[Meta via Digitalmars-d]

On Saturday, 30 May 2015 at 15:24:49 UTC, Adam D. Ruppe wrote:
> 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

This would also greatly improve Variant and Algebraic