OFPEC Forum

Editors Depot - Mission Editing and Scripting => ArmA - Editing/Scripting General => Topic started by: Mr.Peanut on 28 Aug 2008, 21:08:10

Title: The myth of the semi-colon; expression returns
Post by: Mr.Peanut on 28 Aug 2008, 21:08:10

The BI Wiki States:

Quote from: Functions

Return Value
The last expression given in a function is returned to the calling instance. Note that there must not be a semicolon after this value.

return.sqf:
STATEMENT 1;
STATEMENT 2;
RETURN_VALUE

test.sqf:
value = call compile preprocessFile "return.sqf";
// value is now RETURN_VALUE

call compile preprocessFile "return.sqf";
// valid, but RETURN_VALUE is not saved anywhere

and

Quote from: Control Structures

Return Values
Control structures always return the last expression evaluated within the structure. Note that there must not be a semicolon (;) after this value, otherwise Nothing is returned.

Correct example:
if (myCondition) then {myValueA} else {myValueB};

=> returns myValueA or myValueB

Incorrect example:
if (myCondition) then {myValueA;} else {myValueB;};

=> returns Nothing

From looking at SPON CORE I see neither of these is true. Would someone clarify or explain whence this fallacy spawned?

Title: Re: The myth of the semi-colon; expression returns
Post by: Planck on 28 Aug 2008, 21:27:15

Both the areas of the biki you have quoted were mostly written by Hardrock, so presumably he must have tested this at some point.

If you can find him maybe he can cast some light on it.


Planck

Title: Re: The myth of the semi-colon; expression returns
Post by: Spooner on 29 Aug 2008, 01:50:33

The semi-colon after these final statements is optional and its existence doesn't seem to ever affect what is returned. This is exactly the same syntax convention as used in ECMAScript (you will know it as Javascript), and possibly other languages, so it isn't totally weird.

Also, you will have noticed that I always return nil from my functions, if I'm not specifically wanting a return value for the function. The reason for this is to stop the functions returning arbitrary values, that users of those functions may find out about and use. Should I then change the internal implementation of the functions at a later date, then the third-party scripts would break (Yes, this is overly anal, especially in a system without any concept of data-hiding, but I like to do things properly, even if I'm mostly wasting my time ;P).