On Thursday, 29 September 2016 at 07:58:26 UTC, Walter Bright
wrote:
On 9/28/2016 11:48 PM, Jacob Carlborg wrote:
If that is not allowed, why is this allowed:
I.e. you can overload '+' to do bad things. Yes, you can, and
as I replied upthread that can be done because there's no way
to prevent that while having operator overloading at all.
But that is not justification for allowing such disasters for
the comparison operators. I.e. one weakness is not
justification for opening the door to all weakness.
Interestingly, by shutting the door on misuse of the comparison
operators, it seems D has been successful in discouraging
nutburger designs like overloading '+' to mean 'OR'.
The language you just provide a set of tools, then it's up the
to the programmer
to do what he/she wants to do.
That can be used to justify any feature at all.
This is not an argument to justify adding just any feature, it's
an argument that it is idiocy to give a programmer a powerful
tool, and then impose arbitrary limitations upon how they are
allowed to use it.
One of the most popular topics of discussion in this forum is
"Why is D not more widely adopted?" and "What can we do to get
broader adoption for D?"
Perhaps one of the more obvious answers is: Do not prevent
programmers from doing something solely on the basis that _you_
would not want to do it.
I think camelCase is hideous, but does that mean I should forbid
another programmer defining symbols in that style? Of course not.
That they are able to write their code that way doesn't mean I
have to, and doesn't mean I have to use or interface with their
code. I agree that '+' should always mean addition and '~' should
always mean concatenation, but does that mean I should forbid
another programmer from defining them differently? Of course not.
Just because they are able to do it that way doesn't mean I have
to, or that I have to use their code.
If I thought '>' and '<' should always mean arithmetic
comparison, does that mean I should forbid another programmer
from defining them differently?
You need to understand that _you are not the only one writing
code in this language_. Your use cases do not summarize all
possible use cases. That you do not need to use a tool in a
specific way is not a valid argument against allowing others to
use the tool that way.
Give us a rational argument. We are unconcerned with your
personal dogma. What you refer to as a weakness I view as a
strength. Programmers require more flexibility and
expressiveness, not less.
