Re: [fpc-pascal] Operator overload resolution with arrays

2018-02-05 17:12 GMT+01:00 Sven Barth via fpc-pascal < fpc-pascal@lists.freepascal.org>: > Would be good if you'd report them on Mantis nevertheless, cause generics > are a bit of a sensitive area and I'd like to keep an overview there. > I was able to collect list of ~10 new bugs but part of

Re: [fpc-pascal] Operator overload resolution with arrays

2018-02-05 19:54 GMT+01:00 Sven Barth via fpc-pascal < fpc-pascal@lists.freepascal.org>: > Now I see why it is how it is. > > The maximum extent would be to accept overloads (and helpers) that are > visible > at the parameter type's declaration, because they would necessarily be > visible > in

Re: [fpc-pascal] Operator overload resolution with arrays

Am 05.02.2018 17:50 schrieb "Martok" : Am 05.02.2018 um 15:49 schrieb Maciej Izak: > for example final code for TFoo< TSomeArray> will be different than for > TFoo declared in other module (!). Crap. True. Now I see why it is how it is. The maximum extent would be to

Re: [fpc-pascal] Operator overload resolution with arrays

Am 05.02.2018 um 15:49 schrieb Maciej Izak: > for example final code for TFoo< TSomeArray> will be different than for > TFoo declared in other module (!). Crap. True. Now I see why it is how it is. The maximum extent would be to accept overloads (and helpers) that are visible at the parameter

Re: [fpc-pascal] Operator overload resolution with arrays

Am 05.02.2018 15:49 schrieb "Maciej Izak" : specialization for the same generic type can behaves in different way! for example final code for TFoo< TSomeArray> will be different than for TFoo declared in other module (!). What if TFoo has some class var + class constructor ?

Re: [fpc-pascal] Operator overload resolution with arrays

2018-02-05 15:00 GMT+01:00 Martok : > Why? ... > Default property / field or/and aspects is better solution. The way mentioned by Sven with extending generic's scope means almost no control over used operators (or really hard to predict), IMO bad design >.<. Now we have

Re: [fpc-pascal] Operator overload resolution with arrays

Am 05.02.2018 um 15:26 schrieb Martok: > Ah sorry, hadn't seen your message before my last. > >> While specializing the compiler only uses operator overloads (and helpers) >> that >> have been in scope during the declaration of the generic or those that are >> part >> of the types that are used

Re: [fpc-pascal] Operator overload resolution with arrays

Ah sorry, hadn't seen your message before my last. > While specializing the compiler only uses operator overloads (and helpers) > that > have been in scope during the declaration of the generic or those that are > part > of the types that are used for the specialization. This is definitely >

Re: [fpc-pascal] Operator overload resolution with arrays

> Hi, I believe https://bugs.freepascal.org/view.php?id=27690 > is all about it. Looks like it. > IMHO this code shouldn't ever work. Any fix means really mess and hell and > more > problems. Why? As the specialized interface gets

Re: [fpc-pascal] Operator overload resolution with arrays

Am 05.02.2018 13:02 schrieb "Martok" : Hi all, I'm having some logical problems with fgl generic lists and operator overloads. This is essentially the same issue as discussed last year on the forum as . I know

Re: [fpc-pascal] Operator overload resolution with arrays

2018-02-05 13:59 GMT+01:00 denisgolovan : > > Hi, I believe https://bugs.freepascal.org/view.php?id=27690 is all about > it. > IMHO this code shouldn't ever work. Any fix means really mess and hell and more problems. The proper workaround is: * use TTriangleIndex inside

Re: [fpc-pascal] Operator overload resolution with arrays

> Take the following simple declaration: > > type > TTriangleIndex = array[0..2] of Integer; > TFacetList = specialize TFPGList; > > operator = (A, B: TTriangleIndex): boolean; > > This will not work: > fgl.pp(948,50) Error: Operator is not overloaded: "TTriangleIndex" = >

[fpc-pascal] Operator overload resolution with arrays

Hi all, I'm having some logical problems with fgl generic lists and operator overloads. This is essentially the same issue as discussed last year on the forum as . I know how to work around it, just... it doesn't seem very consistent.