> On Apr 18, 2021, at 1:37 AM, Sven Barth <pascaldra...@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.
Regards,
Ryan Joseph
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
