dannym wrote: > hmm.. a parameter declaration of a function declaration is not a > declaration block ? I've always thought of them like local variables, > just happening to be pre-filled..
procedure p(a : array[0..10] of longint); isn't possible either. > > and, will TList<integer> and mylist be compatible types ? > > >>Maybe we need an exception to this when supporting sub routine templates: >>procedure<T> p(mylist : TList<T>); >>begin >>... >>end; >>but this doesn't lead to an ambigious syntax. >> >>- instantiation steps which require code generation are done after main >>program compilation based on information saved in the unit files, this >>has some advantages: > > > you mean to save the parse tree of the generic (both the interface and > the implementation section) to the ppu ? Inlining does this already, the infrastructure is in place. > I've been thinking about using > a extra file in order not to taint the ppu but if it is possible to use > the ppu itself for that, i'm all for it :) > > >>- several equal instantiations require only one specialisation > > > >>- it's possible to setup an symbol environment as it has been used in >>the template definition, so the cyclic unit use problem is void it >>requires though that a lot symbols of the implementation part of a unit >>must be written to the unit file if the unit contains a template definition > > > note that line number information for nice error messages need to be > retained along with the parse tree of the generic (so that when another > unit uses a generic unit but specializes it to something stupid, > programmer gets a nice location of error rather than "guess where it > was" :)). > Maybe it already is done, though :) > > Note that for the error message, you'll need _two_ locations: one of the > generic type implementation where the actual error manifested and one > for the location of the specialization of the generic, to know what has > been used as the type parameter. > > On second though, _maybe_ just one location (the first) and the names of > the types used for the type parameters suffice. For Inlining this works too. > > >>This approach will require some compiler clean ups but that isn't that >>bad ;) >> >>Any comments :)? _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel