operator overloading outside the type

Timon Gehr timon.gehr at gmx.ch
Sat Mar 29 15:47:09 UTC 2025


On 3/29/25 04:52, Jonathan M Davis wrote:
> Yes, and part of my point is that for a number of operators, that's a
> problem, because it would mean trying to overload the default behavior of an
> operator via a symbol which may or may not be imported. Maybe it would be
> okay with something like the arithmetic operators, but for something like
> toHash or opCast, it could cause serious problems.
> 
> For at least some of these operators, the language is designed with the idea
> that they are either always present, or the compiler will generate code on
> its own to use them if they're not, and those absolutely must be part of the
> type, or we'll get all kinds of iconsistencies and hard-to-track-down
> behaviors. Trying to have them be external would be like trying to have copy
> constructors declared externally and be affected by imports.

Well, UFCS cannot override a member function, so there are ways to solve 
this consistently.


More information about the Digitalmars-d mailing list