On Sun, Oct 26, 2008 at 11:02 PM, Simen Kjaeraas <[EMAIL PROTECTED]> wrote: > On Sat, 25 Oct 2008 12:14:47 +0200, Spacen Jasset <[EMAIL PROTECTED]> > wrote: > >> Why unicode anyway? In the same way that editor support is required to >> actually type them in, why not let the editor render them. So instead of >> symbol 'x' in the source code, say: >> >> m3 = m1 cross_product m2 >> >> as an infix notatation in a similar way to the (uniary) sizeof operator. >> >> >> While cross_product is a bit long and unwieldy any editor capable can >> replace the rendition of that keyword with a symbol for it. But in editors >> that don't it means that it still can be typed in and/or displayed easily. >> >> Another option includes providing cross_product as an 'alias' and 'X' >> aswell. >> >> Which then leads on to the introduction of a facility to add arbitary >> operators, which could be interesting becuase you can supply any operator >> you see fit for the domains that you use that require it. -- This provide >> exactly the right solution though as all the additions would be 'non >> standard' and I can see books in the future recommending people not use >> unicode operators, becuase editors don't have support for them. > > This made me think. What if we /could/ define arbitrary infix operators in > D? I'm thinking something along the lines of: > > > operator cross_product(T, U) > { > static if (T.opCross) > { > T.opCross(T) > } > else static if (U.opCross) > { > U.opCross_r(T); > } > else > { > static assert(false, "Operator not applicable to operands."); > } > } > > alias cross_product ×; > > > I'm not sure if this is possible, but it sure would please downs. :P
What's the precedence of your user-defined in-fix operator? --bb