Simen Kjaeraas wrote:
On Sun, 26 Oct 2008 22:28:16 +0100, Bill Baxter <[EMAIL PROTECTED]> wrote:
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
Yup, I realized this myself as well. Seemed like such a great idea when
I only thought of it for three seconds. :p
An operator could always be defined to have the same precedent as an
existing operator, which it has to specify.
Andrei
