[fpc-devel] Generic class comparison operators

Sven Barth pascaldragon at googlemail.com
Wed Apr 21 20:54:36 CEST 2021


Am 21.04.2021 um 16:54 schrieb Ryan Joseph via fpc-devel:
>
>> On Apr 18, 2021, at 1:37 AM, Sven Barth <pascaldragon at googlemail.com> wrote:
>>
>> It has been decided back when operator overloads were introduced that they do not replace existing, built in operators. This decision still stands. And we see no reason to change that. This way a user can *rely* on what a certain operator means based on the language reference guide. This is more important than some convenience for certain use cases.
>>
> We still have some inconsistencies though because of the many other comparison operators which can already be overloaded but simply lack a class operator syntax and thus are not available to classes.
>
> // impossible overload
> operator = (left: TObject; right: TObject): boolean;
>
> // possible overload
> operator = (left: TObject; right: integer): boolean;
>
> // possible overload
> operator < (left: TObject; right: TObject): boolean;
>
> In fact other binary operators that don't have side effects (i.e. don't return the class type) are safe and could be allowed in generic classes also.
>
> // only way to overload + for TSomeClass<T>
> operator + (left, right: TSomeClass<T>): String;
>
> So it's really just about a number of inconsistencies with classes and that's why I wanted to fix it. Same with Objects as Benito has just pointed out again.

You miss the point. The point is that the way it is now *always* 
guarantees that e.g. TObject = TObject *always* behaves the same no 
matter what unit one includes. Same for e.g. String + String, String > 
String, Integer < Integer, etc. And *that* is the consistency that is 
important, *not* that every operator can be overloaded for each 
combination of types. The set of overloadable operators is essentially 
different for each pair of types.
This will not change, because the base rules of the language take higher 
precedence and that would even be something that we likely wouldn't copy 
from Delphi if they'd introduce that.

Regards,
Sven


More information about the fpc-devel mailing list