rvalue types
Dmitry Olshansky
dmitry.olsh at gmail.com
Tue Mar 13 19:14:56 UTC 2018
On Tuesday, 13 March 2018 at 17:33:14 UTC, H. S. Teoh wrote:
>> Now usage:
>>
>> alias powMod = bluePrint.instantiate; // here we do
>> optimizations and CTFE-based codegen
>>
>> powMod(a,b,c); // use as many times as needed
>
> Wouldn't CTFE-based codegen be pretty slow too? Until newCTFE
> is merged, it would seem to be about as slow as using templates
> (if not slower).
Trying to do even most basic optimizations on a bunch of nested
templated types is worst of both worlds: it’s amazingly awkward
_and_ slow. CTFE is almost fine for stright-forward manipulations.
>
>
>> Notation could be improved by using the same expression
>> template idea but with polymorphic types at CTFE.
>>
>> Another thing is partial specialization:
>>
>> alias squareMod = bluePrint.assume({ “b” : 2 }).instantiate;
>>
>> Now :
>>
>> squareMod(a,c); // should be faster the elaborate algorithm
>
> I think the general idea is a good approach, and it seems that
> ultimately we're just reinventing expression DSLs. Overloading
> built-in operators works up to a point, and then you really
> want to just use a string DSL, parse that in CTFE and use mixin
> to codegen.
> That frees you from the spaghetti template expansions in
> expression templates, and also frees you from being limited by
> built-in operators, precedence, and syntax.
Staged aproach has the benefit of composing pieces together +
partial specialization. In a sense “parse the DSL” could do the
same if it splits AST and codegen phases.
More information about the Digitalmars-d
mailing list