On Wed, Nov 30, 2011 at 05:21:09PM -0800, Graydon Hoare wrote:
> I often mentally differentiate these operators:
> + - * / ^ % < <= == => > ! || && []
> From these operators:
> . () ~ @ # &(unary) *(unary)
> In the sense that the former group are "more ALU-like" and the latter group
> are "more load/store/jump-like". Values vs. memory-and-control.
> Do you feel (straw-vote) like you'd be sufficiently happy to be able to
> override the former group but not the latter? Languages vary on how far
> down the rabbit hole of operator overloading they permit, and I wonder
> where each proponent of the concept draws the line. The former group is
> enough to implement most intuitively-arithmetic-ish types, which seems to
> be the big use-case.
I agree that the most pressing need is to provide arithmetic operators
for user-defined types. I'd want the logical operators too.
However, I fear that artificial limitations will simply lead
programmers to re-use the operators they are allowed to overload for
other semantic operations. E.g. message sending as target <= message,
and multi-send as target1 & target2 & ... <= message. (Doesn't even
need parentheses!)
This can be taken as either a good reason not to allow operator
overloading at all, or a good reason to provide user-defined operators
to relieve this temptation.
> (Also: please say you've no interest in permitting user-defined
> operator-symbols with their own associativity and precedence. Right?)
I'm used to them in other languages. They can look confusing when
they're used to express a genuinely difficult concept, but it's
usually the concept that's the problem, not the syntax.
My experience is that macros cause more work for the reader than
user-defined operators.
Jeff Schultz
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
