Hi Hilmar,

Some built-in functions have different return type depending on the parameter passed. For example,

? TYPE([SET("RESOURCE")])  && 'C'
? TYPE([SET("REPROCESS")])  &&  'N'
? TYPE([NVL(Null, DATE())])  && 'D'
? TYPE([NVL(Null, 5)])  && 'N'

So, TYPE() function evaluates its parameter but doesn't look for UDF's for performance reason.


>
>I have seen this problem a few years ago in FoxPro. As to the reasons, I came to the following conclusion:
>
>For a built-in function, VFP (or FoxPro) knows the expected return type. The type can be determined without actually evaluating the function.
>
>For a UDF, there is currently no way to tell VFP that your UDF normally returns such-and-such a type. There is no way for VFP to tell you the type of the expression without actually calling the function. This may have undesirable side-effects: your UDF might do almost anything, or produce an error.
>
>For these reasons, although it is unpleasant not to be able to easily get the type of your expression with type(), I find VFP's behavior perfectly logical.
>
>Regards,
>
>Hilmar.