On Friday, 10 March 2017 at 19:02:06 UTC, H. S. Teoh wrote:
On Fri, Mar 10, 2017 at 07:47:43AM +0000, XavierAP via
Digitalmars-d wrote:
On Thursday, 9 March 2017 at 15:42:22 UTC, qznc wrote:
[...]
> Maybe we want to support weird DSLs, where operators are
> reused with very different semantics? For example, the
> pyparsing parser generator allows you to write a grammar
> like [0] this:
Maybe... I usually hate that stuff a-la-C++ iostream but,
inverting the question, do you want to disallow it?
AFAIK Walter's stance is that overloading operators with
semantics other than generalizations of arithmetic operators
are a bad idea. This is why D uses opCmp for overloading <,
<=, ==, >=, >, instead of one overload per operator like C++
has. Separately overloading < and <=, for example, means that
the programmer can do truly weird things with it, which makes
code hard to read (when you see "a < b" and "a <= b", you have
no idea what they *really* mean).
* D does not use opCmp for == but I'm sure it slipped your tongue
;)
I agree with that stance on style myself, and also with the hard
restriction to keep the (in)equality and comparison operators
consistent with each other. But the question is whether to
restrict programmers further with no other reason than style. D's
philosophy is maximum @system freedom (just like C/C++) within
sanity.
Also operator overloading style may depend on each engineer's
background. Walter's education is mechanical engineering and
mathematics (coincidentally just like myself), so he dislikes
usage of operators not analogous to algebra or set theory. Me
too; beyond that I would rather create methods with
self-documenting names.
But there are software engineers and computer scientists who
don't care about math, and they may even love iostream's "arrows"
indicating the direction of the "stream". Leaving aside the
specific example of iostream, this style discussion is not one
where anyone can prove or claim to be right. Live and let live.
