clipper calling convention. ( VO and FP )
This code compiles and runs even though the datatype of the return value is declared.
FUNCTION Start() AS VOID
? ClipTest1() == 0
? ClipTest2() == NULL_STRING
? ClipTest3() == NULL_ARRAY
? ClipTest4() == NULL_SYMBOL
? ClipTest5() == NULL_CODEBLOCK
RETURN
FUNCTION ClipTest1 ( a , b , c ) AS FLOAT CLIPPER
RETURN NIL // <------
FUNCTION ClipTest2 ( a , b , c ) AS STRING CLIPPER
RETURN NIL // <------
FUNCTION ClipTest3 ( a , b , c ) AS ARRAY CLIPPER
RETURN NIL // <------
FUNCTION ClipTest4 ( a , b , c ) AS SYMBOL CLIPPER
RETURN NIL // <------
FUNCTION ClipTest5 ( a , b , c ) AS CODEBLOCK CLIPPER
RETURN NIL // <------
Karl-Heinz
Karl-Heinz, Yes, and this is by design.
For the compiler this is the same as
FUNCTION ClipTest1 ( a , b , c ) AS FLOAT CLIPPER
LOCAL u := NIL AS USUAL
RETURN u
There is an implicit conversion from the USUAL type to all of the types that you have specified. So the compiler will generate something like this:
FUNCTION ClipTest1 ( a , b , c ) AS FLOAT CLIPPER
RETURN (FLOAT) NIL // <------
At this moment this returns 0, but I tested this in VO and it should produce a (runtime) error.
See https://github.com/X-Sharp/XSharpPublic/blob/main/src/Runtime/XSharp.RT/Types/Usual.prg#L2404
Robert
Robert,
RETURN (FLOAT) NIL // puuh, never thought that something like this is legal.
At first sight i thought VO throws an compile error, but it´s a warning e.g. "converting NIL->STR:51423". And yes at runtime a NIL-> FLOAT throws an DATA TYPE ERROR. The only line that works is:
? ClipTest3() == NULL_ARRAY
But do you agree, that X# should throw a warning like VO does ?
Karl-Heinz
Karl-Heinz
"should throw" no. "would be nice if it throws", yes.
The problem is that the code that decides if a conversion from one type to another type is implicitly supported by the language would then also have to take into account if that type is stored in a variable or if that type is defined in a literal.
At this moment the code does not do that. And when we do make that distinction then we have to make sure that the same rules are defined in the runtime and in the compiler. It may be tricky to keep these in sync.
Robert