I have a numerical/multimedia library that defines the concept of
an n-dimensional function sampled on a grid, and operations on
such grids. `InputGrid`s (analogous to `InputRange`s) can be
dense or sparse multidimensional arrays, as well the results of
lazy operations on other grids and/or functions
(map/reduce/zip/broadcast/repeat/sample/etc.).
UFCS has been extremely beneficial to my API, enabling things
like this:
DenseGrid!(float, 2) x = zeros(5, 5);
auto y = x.map!exp.reduce!max;
without actually defining `map` inside `DenseGrid` or `reduce`
inside `MapResult`. `map` and `reduce` are defined once, at
module scope, and work with any `InputGrid`.
As this is numerical code, it would be great to be able to do
this with operators, as is possible in C++, Julia, and F#:
auto opUnary(string op, Grid)(Grid g) if (isInputGrid!Grid)
{ /* Enable unary operations for *any* `InputGrid`. */ }
DenseGrid!(float, 2) x = zeros(5, 5);
auto y = -x;
This is currently not supported, which means users of my library
get functions like `map` and `reduce` that work "out of the box"
for any grids they define, but they need to do extra work to use
"convenient" operator syntax for NumPy-style elementwise
operations.
Based on my limited knowledge of DMD internals, I take it this
behavior is the result of an intentional design decision rather
than a forced technical one. Can anyone explain the reasoning
behind it?
Also, does anyone else have an opinion for/against allowing the
definition of operators that operate on concepts?
Thanks for your time,
-MM
