Hi Elan, You wrote: > I don't see any harm in having a type specifier as part of > the function declaration, which enforces a return type ... > as long as it's *optional* ;-). How would this be enforced in an interpreted language that creates its functions at runtime? Testing for return type at function creation time would need a type-inference engine to determine the type. Type inference is too slow to do at runtime. Testing for return type at function execution time would add an type-checking exception after the end of the function block. The function code wouldn't be able to handle such an exception, so it would have to ensure that the error couldn't occur using internal error-checking code, which would mean that the built-in return type-checking code would just be overhead. > Something like: > > func [ a [any-type!] b [integer!] /local ... /return [any-type!]] [ > ] > > Perhaps with auto-conversion? I noticed that you put the return type you listed was in a block. Blocks are used for the other types so that multiple types could be specified. If multiple types are specified, which type do you auto-convert to? What about conversions that aren't so automatic? Functions in REBOL are often polymorphic, returning types that depend on the types or values of their arguments. Any conversion or type checking in such an environment is better done manually. It's usually faster too, because you can remove tests where they aren't needed. A type inference engine would be a great development-time tool to check your code before release, though. It would be a good thing to have for documentation too. Wanna write one? ;-) Brian
