Michael Van Canneyt wrote: > 1. What happens if f would use a variable from somefun, and f is called > when somefun is no longer executed ?
This can not happen when the function parameter cannot be stored anywhere. > 2. I see no difference whatsoever between typ_fun and iso_fun, except > the use of an extra type, which, in my opinion, does not change > anything to the usage or code of these functions. If one is allowed, > the other should be allowed as well. As I understand the ISO convention, it just shall disallow to create variables of the procedural type, which were required to store such a reference. In Pascal two type declarations are different, even if they look the same. Let me add some more thoughts about procedural types: - I like the ability to declare procedural types, the ISO convention looks like one of the many incredible C hacks to me :-( - For the restricted use of local subroutines as procedural parameters I could imagine a "const" prefix in the accepting procedure declaration: procedure my_fun(const pf: tfun); The "const" prefix here means that the procedure pf only can be called, but cannot be stored in a variable. The compiler then can assure that local subroutines are passed only as const arguments. This syntax requires no changes to the parser. The compiler message for a missing "const" could be a warning instead of an error, to prevent compatibility/portability problems. Other compilers should ignore the "const", so that accordingly modified source code still should be portable? Hmm, the hidden frame parameter still will make a difference with local subroutines. At least in Pascal calling convention, where the arguments are popped by the called subroutine, not by the caller... - I'd appreciate to define procedures based on procedural types as well. Currently a change to the procedural type requires updates of all derived procedure declarations. Something like: myproc: tfun = begin blabla end; IMO such a definition would better implement the strict Pascal typing, instead of only a type equivalence determined by the procedure signature. Unfortunately(?) this syntax is incompatible with procedural variables, so that it would disallow to create such variables. A "procedure" prefix would make the definition look like a function returning an TProcType. But perhaps somebody has a better idea? DoDi _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
