[fpc-devel] Generic class comparison operators

Benito van der Zander benito at benibela.de
Wed Apr 21 15:44:33 CEST 2021


Hi,

  what about overloading operators for OBJECTs?

They do not conflict with any default operators.

I expected this to work, but it did not compile:


   type generic TXQHashset<TKey, TInfo> = object //(specialize 
TXQBaseHashmap<TKey,TXQVoid,TInfo>)...
     class operator =(const a, b: TXQHashset): boolean;
   end;


Cheers,
Benito
On 17.04.21 22:12, Jonas Maebe via fpc-devel wrote:
> On 2021-04-17 22:02, Ryan Joseph via fpc-devel wrote:
>> Since I'm working on generics right now can we finally, at the very
>> least, allow class operators for comparison operators? This is
>> literally the only way for a generic class to override the = operator
>> (along with some others) so there's no reason not to allow this. I
>> understand the objection to :=, + etc.. where it returns a copy of a
>> class instance and people could in theory do memory unsafe things,
>> with comparison operators there is no possibility for this. I already
>> made a patch for "advanced records" which is in limbo but It's trivial
>> to adapt this for classes and put restrictions on the type of
>> operator.
>
> The issue with allowing it for classes (generic or not) is that the 
> the = operator already has a meaning for them (pointer equality). I 
> think in general we don't allow overloading operators that have a 
> built-in meaning.
>
> It would work very well either, because if you'd pass such a class 
> instance as a TObject parameter and that called routine performs a 
> comparison, then suddenly the comparison would happen again based on 
> pointer equality rather than with this custom operator. This means 
> that e.g. any non-generic container class that uses comparisons (for 
> sorting or for detecting duplicates) would fail to work, or at least 
> work differently than generic container classes. That's something you 
> don't want at all in a programming language, as it means you 
> constantly have to keep in mind how something you call was implemented 
> to know how it will behave (the called routine may even have your 
> class type as parameter type, but then call something else that uses 
> TObject).
>
>
> Jonas
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20210421/c2f97b13/attachment.htm>


More information about the fpc-devel mailing list