✨
New development build available. Testers wanted.

As seen on https://www.qb64.org/forum/index.php?topic=704.msg5775#msg5775

So up until v1.5 QB64 contained a bug that wouldn't allow recursion involving a function without parameters. This was incompatible with our mother ship, QuickBASIC 4.5, and in the upcoming v1.6 we will have that behavior fixed.

Drawing from the post I linked above, the code...


...will now properly print 5 stars and the number 1 before it ends, because the assignment line F = F will properly call Function F, as one would expect.

This means you shouldn't work with the return variable of a function as a regular variable. The best practice/approach is to have a temporary variable in case you need to build the return value as the function is processed, and only in the end of the procedure do the functionName = returnValue assignment.

Let me know how the new dev build will deal with your existing code, while keeping the above observations in mind.

And thank you for flying QB64.
✈️

Well, to clarify that condition somewhat better:

• you can assign return values to the function name (ie. the function name is on the left side of the equal sign (=)) as often as you want and in any place within the function, eg. assigning different values from within different cases of a SELECT CASE block
• however, if the function name appears in any arbitrary term/formula on the right side of the equal sign (=), then it will in fact be a recursive call of the function, and hence the result of that function call is injected into the term/formula, rather than any value assigned to the function name anywhere earlier within the function
• if doing the latter, be aware that your function gets recursive calls and hence must define any suitable end condition to avoid stack overflow crashes

Is that so far correct @FellippeHeitor, or are there other points to be aware of?

Spot on, Rho.

Exactly due to being a breaking change, we’re internally coming to final terms on bringing the version bump to 2.0.

Exactly due to being a breaking change, we’re internally coming to final terms on bringing the version bump to 2.0.

I hope you made sure, that this change doesn't bite your own butt within QB64.bas and all the other basic source files involved, would be too bad, if QB64 breaks itself by enforcing the new behaviour.

At least for my GuiTools the impact is much higher than expected first, as things like assigning a result value through an intended argument side effect of a SUB call won't work anymore.

eg:
SetTag ButtonC$, "ERROR", classID$ + "::" + methodID$ + " -> missing required tags"

that's a typical line in GuiTools, ButtonC$ is the actual function name, and the final error tag assembled by the SetTag SUB was then returned in ButtonC$ as side effect, but now ButtonC$ would call the Button class instead.

I've to find a new elegant method now to do this in a similar way, as simply each time using a temp variable in the SetTag call and afterwards assigning that to the class its function name seems much to plumsy for me.

Btw, are you not on Discord for moral issues or are you just not a chat room guy? Your input in the dev lounge is always very welcome and appreciated.

Not a chat room guy, also with nursing my sick old mom (87y) no time to engage in (almost) real time discussions.

I’m running into the same issues with a lot of my stuff, particularly with regards to direct assignment issues.

FUNCTION foo$ (filehandle, line)
   SEEK #filehandle, 1
   FOR I = 1 TO line
      IF EOF(filehandle) THEN foo$ = “ERROR, PAST END OF FILE”: EXIT FUNCTION
      LINE INPUT #filehandle, foo$
   NEXT
END FUNCTION

Gets, puts, inputs, prints…. I have a ton of these which just referenced the function name as a variable name, which are going to need alterations.

I imagine we’re going to see a slew of reports about libraries erroring out with the next version update, and the librarians will need to check the code in the forum’s library area to test and make certain everything there works as advertised in the future. (The “Samples Gallery & Reference area now.)

will recursion still work?

Is that a question for me?
If so, it displays the result 120 after compilation