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.
