mixin not overloading other mixins, Bug or feature?
BCS
none at anon.com
Wed Dec 23 12:28:59 PST 2009
Hello Travis,
> BCS wrote:
>
>> By don't overload, I'm taking about "defined to not overload".
>>
>> That removes "bug" leaving "misfeature", and "feature".
>>
>> I think the rational is that allowing them to overload makes the
>> order
>> of expansion hard to impossible to work out.
>> For example:
>> template Bar(T) { const bool v = true; }
>> template Foo(T)
>> {
>> static if(Bar!(T).v)
>> template Bar(U : T) { const bool v = false; }
>> else
>> template Bar(U : T) { const bool v = true; }
>> }
>> mixin Foo!(int);
>>
>> static assert(Bar!(char)); // works
>> static assert(Bar!(int)); // what about this?
>> By making mixins not overload, many (if not all) such cases become
>> illegal.
>>
> I'm not fully sure this applies to my issue, maybe it is because I am
> not fully sure how templates are implemented (in my mind, I think
> something similar to macro expansion).
Using CTFE, the above can be recast using functions. Or if you want to get
tricky you can play games with different return types and generate the same
kind of paradoxical results.
>
> My issue is with function overloads. 2 functions, same name,
> different parameters. Right now my only solution is hacky string
> mixins.
>
> It seems to me that 2 templates should be able to mix into the same
> struct, overloading the same functions, if:
>
> 1. They don't contain the same parameters with eachother. If they do,
> then conflict.
>
> 2. They don't contain the same parameters of the struct they are
> mixing into. If they do, then use the one in the struct (like it
> works now).
>
That might work if you add "3. They have no effect on any overloading choices
that were needed (directly or indirectly) to instance the template." But
that might not be a reasonably computable criteria. And if it is reasonable,
you can bet your socks it will be bug bait.
More information about the Digitalmars-d
mailing list