On 07/03/11 01:01, Caligo wrote:
On Sun, Mar 6, 2011 at 12:24 PM, Peter Alexander <peter.alexander.au
<http://peter.alexander.au>@gmail.com <http://gmail.com>> wrote:
On 6/03/11 4:22 PM, bearophile wrote:
So I think it's not worth adding to D.
But if you don't agree... talk.
Bye,
bearophile
I agree.
It would be nice in some situations (like cross and dot products for
vectors), but otherwise it's unnecessary and just adds confusion in
exchange for a tiny but of convenience in a handful of scenarios.
With C++, for example, Eigen uses expression templates. How does one do
expression templates in D? Could someone rewrite this
http://en.wikipedia.org/wiki/Expression_templates this D?
>How does one do expression templates in D?
Same basic idea but it should be a lot saner because D metaprograming
isn't a Turing tar pit like with C++. The return type of your function
is a template encoding in types of the inputs. So you could define an +
operator that has a return type of
opBinary(RHS,"+",LHS)
Or similar. The type of RHS and LHS could be other opBinary
instansiations or a leaf time. Sooner or later you've got something that
looks like a parse tree and you can process that at compile time using
CTFE and then mixin the result. Heck, you might even be able to do
something crazy like flatten the tree and re-parse and thus screw with
the operator precedence or run your own specialized compiler backend and
output inline asm.
Trouble is, each time I feel motivated to give this a go I run into
compiler bugs. Hopefully things will get better soon.
