Re: [fpc-devel] Generic class comparison operators
> On Apr 21, 2021, at 12:57 PM, Sven Barth via fpc-devel > wrote: > > You can only use global operators with objects. yes but not with *generic* objects. I find it very hard to understand why this is being blocked for objects. Without this there is no way to have *generic* record inheritance in Pascal. Is this seen as a problem or something that people would make a generic inheritable record type? Without this we have stupid things like having to reimplement TVec2, TVec3, TVec4 etc... because we can't simply inherit from the previous type. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generic class comparison operators
Am 21.04.2021 um 15:44 schrieb Benito van der Zander via fpc-devel: 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 = object //(specialize TXQBaseHashmap)... class operator =(const a, b: TXQHashset): boolean; end; You can only use global operators with objects. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generic class comparison operators
Am 21.04.2021 um 16:54 schrieb Ryan Joseph via fpc-devel: On Apr 18, 2021, at 1:37 AM, Sven Barth 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 operator + (left, right: TSomeClass): 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generic class comparison operators
> On Apr 18, 2021, at 1:37 AM, Sven Barth 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 operator + (left, right: TSomeClass): 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. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generic class comparison operators
> On Apr 21, 2021, at 7:44 AM, Benito van der Zander via fpc-devel > wrote: > > 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 = object //(specialize > TXQBaseHashmap)... > class operator =(const a, b: TXQHashset): boolean; > end; yes I have patch to enable this via a mode switch (https://bugs.freepascal.org/view.php?id=36350) but it has been acknowledged and then ignored without explanation since 2019. This is still the only way we can use operator overloads for generic objects and objects are the only way to have record inheritance so it's a critical missing feature in my opinion. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generic class comparison operators
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 = object //(specialize TXQBaseHashmap)... 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@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generic class comparison operators
Ryan Joseph via fpc-devel schrieb am So., 18. Apr. 2021, 02:18: > 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. > 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. Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generic class comparison operators
> On Apr 17, 2021, at 2:12 PM, Jonas Maebe via fpc-devel > wrote: > > 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. I see your point about there being a conflict for pointer quality but you can actually resolve it by casting to TObject, however as you note it could be confusing also. That's an interesting question I'd need to think about more but even so that is only the = operator with other pointer types. Here's the list of possible operators that don't have side effects to the caller and are worth considering and may be safe. class operator = (left: TSelf; right: TRight): boolean; class operator not (left: TSelf): boolean; class operator <> (left: TSelf; right: TRight): boolean; class operator < (left: TSelf; right: TRight): boolean; class operator > (left: TSelf; right: TRight): boolean; class operator <= (left: TSelf; right: TRight): boolean; class operator >= (left: TSelf; right: TRight): boolean; class operator >< (left: TSelf; right: TRight): boolean; class operator in (left: TSelf; right: TRight): boolean; Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generic class comparison operators
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@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Generic class comparison operators
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. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
