"Patrick Down" <pat@codemoon.com> wrote in message news:Xns93F3E63E057FBpatcodemooncom@63.105.9.61...
> I would like to have multidimensional indexing and slicing too.  I prefer the array[x,y] syntax.  I don't think that you need to support it as a basic feature of D arrays but it would be nice to define classes that would support it.

That might be a good compromise.

"Walter" <walter@digitalmars.com> ha scritto nel messaggio news:bjqhdm$ja4$3@digitaldaemon.com...
> That'll work, but it just doesn't look like much of an improvement :-( Anyhow, I'll think about it some more.

I certainly didn't even try to think how it would be implemented in the compiler... or you can be sure I'd have overlooked at least 80% of relevant issues, due to total inexperience in the field.

But, from my perspective as a _user_ of compilers, this seems, more or less, the way to go (note that I've have little second thoughts with respect to my previous post):

1) the "operator" keyword makes code clearer at the first glance. This is maybe the only place where, IMHO, C++ looks better than D. To be truthful, I should also mention templates, but that's another story (and another thread).

2) Prefix and postfix ++ and -- need not be distinguished, _if_ in the postfix case you call the op-function immediately after evaluation of the subexpression containing the operator. So:

if (++b > 42)

would be the same as "b.operator ++(); if (b > 42)", while

if (b++ > 42)

would be the same as "bool temp = (b > 42); b.operator ++(); if (temp)"

Again, I don't know if and how much this is practical for you as the compiler's author, but I see no use for two separate ++ operators, other than letting people hurt themselves... :)

3) For non-commutative binary operators, I see two possible ways: either a "reverse" attribute, with the same meaning as the "_r" suffix in current op-funcs, or not having them as members, so they take two parameters whose order is obviously specified in the declaration.

4) Following the same line of thinking, I'd suggest a "lvalue" attribute for the assignable index operator: "operator lvalue []" as opposed to "operator []" which does not (necessarily) return a lvalue.

5) a[3][5] and a[3, 5] are different beasts, I see no need for compiler intervention here.

Hope I didn't forget anything this time. :)
Ric

> I like this approach for the indexing operator.  I don't have a big opinion on the exact function names but I'm in the op_add, op_mul, op_whatever camp.

I've revised my antipathy to ambiguousness upwards, and now will be unhappy with anything less than the Python-esque __op_add__, __op_index_l__, etc.

I'm not holding my breath ... ;(