Error XS0161 not all Code paths Return a Value

[Anonymous]

In FoxPro, by default if a Function does not have an explicit RETURN statement, it returns a value of .t.

In X# (Ver 2.08), you get a compiler error if no RETURN statement is present.

Can X# inject a RETURN .T. (somehow) underneath the covers so that we don'y have to modify hundreds of code files if we ever import a big VFP project into X#?

Or is there a flag to handle this with manually editing every function to add a RETURN statement?
.

2019-10-17_16-24-59.png (17.98 KiB) Viewed 285 times

[robert]

Matt.
- This is not really an error but a warning. I think you have the compiler option "warnings as errors" enabled
- If you enable compiler option /vo9 then the compiler will automatically add the right return value to functions/methods that are missing these.

Robert

[FoxProMatt]

Robert - help file say -v09 means “Allows missing RETURN statements”, but it’s not clear if this is the same thing as having the Function return .T. as a value, as is the case in VFP.

Can you clarify?

[robert]

Matt,
[Soapbox on]
Let me start with repeating that I think that it was a VERY bad idea from the VFP dev team to allow procedure to return value. Early in the dBase days we only had procedures and they did not return anything. You called hem with the DO <proc> WITH <params> syntax. Procedures had no return values and therefore variables that were passed to them would be passed by reference. Foxbase and Clipper introduced "User Defined Functions" that would take parameters by value and return values. It has stayed like that in all xBase languages, except obviously VFP. I am not sure when procedures with return values were introduced but I think it was a historical mistake.
[Soapbox off]
To answer your question: the /vo9 compiler option is an option that we "inherited" from Vulcan. This option takes care of a lot of problems w.r.t. return statements and return values. We have expanded this option to also fix problems with procedures in the FoxPro dialect:
- when a function does not have a return statement it will add a return statement with a blank value of the proper type. In the case of a function that returns a logic, this blank value will be a FALSE. An untyped function / method will return NIL.
- when a function has a return statement without a value then it will add a return value of the proper type

In the FoxPro dialect we have changed a few things
- Procedures can now return a value (in the other dialects they can't)
- NIL is no longer a 'void' value but it has a value of False.
- Untyped functions and procedures still return NIL, which has a value of False

Robert

[FoxProMatt]

1. VFP Procedures and Functions can also return an Object.

Is that something this is, or will be, handled in the X#.VFP dialect?


2. Do we define a Function as a freestanding Function outside of a Class, and a Procedure (Method) as a Method on a Class. Even in C# a Method on a Class can return a value or object. I’m assuming you don’t have any beef with Method on a Class returning a value but your beef is simply with a single Function outside of a Class returning a value. Is that right?

[robert]

Matt,
1) VFP procedures in X# can return anything. If you do NOT declare them "AS Sometype" they are assumed to return a USUAL which can have any value that you like. I was referring to the default return value that the compiler has to generate if you are not returning something yourself.

2) There is no real difference between the 2 in the VFP dialect in X#. The only difference is that inside a class function and class procedure you can refer to THIS/SELF. In a freestanding function THIS and SELF are not available because they are compiled to what C# calls "static" methods.

The compiler is creating methods for all functions and procedures. The free standing methods will become static methods in a compiler generated Functions class in a namespace that is derived from the name of your assembly. So the fully qualified name for the functions class in MyFirstProject.DLL will be be MyFirstProject.Functions. In the case of myFirstApp.exe this name will be MyFirstApp.Exe.Functions.

Robert

[FoxProMatt]

Okay so I am trying to understand your complaint about Functions returning a value?? Even in C# a method on class returns a value. It's a very powerful and commonly used thing, so what your [soapbox] about
.

"Let me start with repeating that I think that it was a VERY bad idea from the VFP dev team to allow procedure to return value. "

What am I missing??

[Chris]

Hi Matt,

Robert was referring to _procedures_, not functions,

[FoxProMatt]

Robert was referring to _procedures_, not functions,

.
Okay that's what I was trying to differentiate between free-standing Functions (outside of a class), versus Methods on a Class (Procedures).

Sadly, in VFP world "Function" "Procedure" "Method" are often used interchangebly, leading to confusion, and I think you can code it out either way, and it all still runs the same exat way at run time.

VFP refers to "Methods" all over the place in Help, but there is not even a METHOD keyword. And you can use FUNCTION and PROCEDURE either one when writing CLASS code.

[Chris]

Hi Matt,

But how can they be used interchangeably, when they have different semantics in VFP? Functions pass values by value, while Procedures pass values by reference. We do not have that difference in VO (or other xBase dialects that I know of), but this behavior will be implemented for the VFP dialect.