Overloading relational operators separately; thoughts?
Minty Fresh via Digitalmars-d
digitalmars-d at puremagic.com
Fri Sep 30 05:31:45 PDT 2016
On Friday, 30 September 2016 at 00:50:54 UTC, Jonathan M Davis
wrote:
>
> Except that it kind of is. It's an example of a language
> allowing you to mess with too much and make it so that it
> doesn't function as expected, which is what happens when you
> overload operators to act in a way inconsistent with how they
> work with the built-in types. The perl example is more extreme,
> but the point still stands that having normal, common
> constructs operate in a way that's inconsistent with how they
> normally work tends to make code harder to read and maintain.
> Certainly, it can result in very unexpected behavior when
> mixing it with generic code that uses those operations.
>
> - Jonathan M Davis
It's up to the developer to ensure that their code works
correctly with existing facilities, not the language. I can
already write code that will work in amazing and ridiculous ways
with generic code in the standard library. It does not follow
that the language is responsible or at fault for the code
behaving in ways that are unexpected.
Furthermore, it's completely reasonable to write code that works
with the generic facilities in the standard library, even if it
doesn't behave exactly like a built in type.
ie.
foo.reduce!"a + b"; // => produces an integer
bar.reduce!"a + b"; // => produces an AST node
So long as the types produced by the operation are correct, this
will work just fine.
More information about the Digitalmars-d
mailing list