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