Am 22.04.2011 12:06, schrieb michael.vancann...@wisa.be: > > > On Fri, 22 Apr 2011, Florian Klämpfl wrote: > >>> mya.pp(16,12) Error: Operator is not overloaded: "complex" + "complex" >>> myb.pp(9,14) Fatal: There were 1 errors compiling module, stopping >>> >>> Which is strange to say the least, as the per the definition/intent of >>> generics, the code in mya should not know anything about the types that >>> will be used when specializing. (in this case complex). >>> >>> As per the intent of generics the second program above should compile >>> just as well. >>> >>> But then different rules will apply for operators and procedure calls: >>> - procedure calls must be resolvable at define time >>> - Operators must be resolvable at specialization time. >>> No principal problem (we can define it so), but strange at least. >>> >> >> It is correct that the second doesn't compile. To make the second >> compile, the overloaded operators for the complex type must be defined >> inside complex (which was/is? not possible). > > > 1. The + is not defined 'inside' integer either. Why should it be > required for a record ?
Internal types are special. > What kind of strange reasoning is that ? Are we going to redesign > operators for records ? For pascal like generics it might be necessary to rethink some design considerations, yes. > (I suspect this is why it is possible to add type restrictions in the > Delphi/.Net implementations) > > 2. If I have my own overloaded version of '+' for a record, the above > means that it > cannot ever be used for generics, while it will be used for all my > other code. > > Say I define a type, and decide not to put the operators inside the record, > for whatever reason. I am happily unaware of generics. Along comes an > afficiniado of generics, and wants to use my type in generics, but hits > the above problem. He is stuck. No. He can define a record helper operator. The question is simple: do we want generics behave like macros or more like .Net generics. Some hybrid approach is imo wrong. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
