Operator/concept interoperability

[Mason McGill via Digitalmars-d]

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