Overloading relational operators separately; thoughts?
Minty Fresh via Digitalmars-d
digitalmars-d at puremagic.com
Fri Sep 30 13:14:11 PDT 2016
On Friday, 30 September 2016 at 19:46:35 UTC, bachmeier wrote:
> Claiming that operator overloading only applies to a specific
> user-defined type makes it worse. Having it work one way for
> three types, a different way for four other types, and a third
> way for yet another type doesn't sound like a minor thing.
But operators already behave in different way for different
types. Built-in types inclusive. The most trivial and nit-picky
difference would be between integer types and floating point
types.
ie. Division between two integers yields an integer, division
between two floats yields a float, but then division between an
integer and a float also yields a float.
Alternatively, the bit-shift operators `<<` and `>>` don't
function at all for floats.
But then we have also wonderful floating point values like `NaN`
and `Infinity` for which arithmetic and relational operators
behave differently altogether.
Another would static arrays, versus dynamic arrays, versus
associative arrays. The first two support concatenation via `~`,
only the second supports in-place concatenation `~=`, and the
last has no notion of concatenation at all.
A counter argument that might be raised is that those are
different types altogether. They are intended to behave in
different ways entirely. Completely different data structures.
Their similarities are only superficial.
And such a counter argument would be absolutely correct. Markedly
so. They are completely different types.
The same is true of user-defined types. Their behavior should not
be equated to (nor expected to be like) the behaviors of types
they only resemble superficially.
> But have fun debating design decisions that were made long ago
> and aren't going to change.
That's exactly the kind of decision making you see in C++ and
PHP. Metathesiophobia would be one way of describing it. Stubborn
blindness to real world usage is more contextually appropriate
though, I feel.
More information about the Digitalmars-d
mailing list