What about the following convention that would at least attract attention to the fact that we are dealing with custom/overloaded operators?
foo + bar // usual operator foo `+` bar // regular function "+" with infix notation foo `plus` bar // regular function "plus" with infix notation In which functions "+" and "plus" can be overloaded in some manner. Also, yes, custom precedence and associativity sounds like a bad idea. Cheers, David On 12/1/11 2:21 AM, Graydon Hoare wrote: > On 11-11-30 03:08 AM, Marijn Haverbeke wrote: >> https://github.com/graydon/rust/wiki/Interface-and-Implementation-Proposal >> > > Looks good to me. At least the first chunk. Gets a bit more debatable in > the "Extensions" part, but we can cross those bridges later. > > Concerning operator overloading (as I gather there are >1 fans of it here): > > 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. > > (Also: please say you've no interest in permitting user-defined > operator-symbols with their own associativity and precedence. Right?) > > -Graydon > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
