Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow function return values using EXIT FUNCTION [returnvalue] #212

Open
a740g opened this issue Oct 19, 2022 · 13 comments
Open

Allow function return values using EXIT FUNCTION [returnvalue] #212

a740g opened this issue Oct 19, 2022 · 13 comments
Labels
enhancement New feature or request

Comments

@a740g
Copy link
Contributor

a740g commented Oct 19, 2022

This was originally requested in QB64Team/qb64#225 using the keyword RETURN.

However, the RETURN keyword is used while returning from GOSUBS and can take an optional label which can lead to complications if it doubles as a return statement for FUNCTIONS.

Hence, the suggestion is to use the following syntax:

EXIT FUNCTION [returnvalue]

Leaving the below link here for future discussions.
https://qb64phoenix.com/forum/showthread.php?tid=1100

@a740g a740g added the enhancement New feature or request label Oct 19, 2022
@RhoSigma-QB64
Copy link
Member

What's wrong with this? All this just to save the additional error assignment? Would seem rather confusing to me to place anything after EXIT FUNCTION. However, it's not a strict NO, but rather a think twice :), I'd certainly not use it, even if it's available.

  FUNCTION foo
      IF wrong THEN foo = failed: EXIT FUNCTION
      foo = success
  END FUNCTION

@a740g a740g changed the title Allow functions return values using EXIT FUNCTION [returnvalue] Allow function return values using EXIT FUNCTION [returnvalue] Oct 19, 2022
@a740g
Copy link
Contributor Author

a740g commented Oct 19, 2022

What's wrong with this? All this just to save the additional error assignment? Would seem rather confusing to me to place anything after EXIT FUNCTION. However, it's not a strict NO, but rather a think twice :), I'd certainly not use it, even if it's available.

Nothing really. I've always used that with QB45. With VB, I switched to using Return within functions.
I agree this is just syntactic sugar. However, IMO, it does makes code easier to write and read.
Not a high priority stuff. But just wanted to put this here so that we don't forget about it.

@ghost
Copy link

ghost commented Oct 19, 2022

I'd definitely use it. If anything, just to force people to upgrade their version of QB64pe so they can run my code 😁

@mkilgore
Copy link
Contributor

I don't know about the proposed syntax (that's easy to change, however), but I think it's worth it to add this since it allows you to avoid writing the function name everywhere you return a value. With the way it currently works if you rename a function you have also change every spot a value is returned, and if you miss one you don't necessarily even get an error. Having a Return-like statement allows you to rename the function without having to change the body of the function at all, which is a big advantage. Additionally it's easier to read, since it's unambiguous between returning a value vs. assigning a variable.

Certainly it's not strictly necessary, but then many of the existing statements are not actually "necessary", they exist purely because they can be used to make your code better. IMO this falls into that same category.

I will say I like the EXIT FUNCTION [returnvalue] syntax less and less the more I see it :P Perhaps just a completely new keyword would be better...

@RhoSigma-QB64
Copy link
Member

With the way it currently works if you rename a function you have also change every spot a value is returned, and if you miss one you don't necessarily even get an error. Having a Return-like statement allows you to rename the function without having to change the body of the function at all, which is a big advantage.

However, if it gets implemented some day, then for consistency END FUNCTION must also be able to take a return value. It makes no sense to allow that for EXIT FUNCTION, but require the assignment to the function name for the regular function end.

@a740g
Copy link
Contributor Author

a740g commented Oct 19, 2022

Having a Return-like statement allows you to rename the function without having to change the body of the function at all, which is a big advantage.

This is an excellent point.

I will say I like the EXIT FUNCTION [returnvalue] syntax less and less the more I see it :P Perhaps just a completely new keyword would be better...

Now that you said that, I too see the ugliness. 😄 ASM-like _RET perhaps? I dunno. 😁

@glasyalabolas
Copy link

Why not just return( value )?

@mkilgore
Copy link
Contributor

Why not just return( value )?

I think the risk of mistakes is a bit high, leaving off the parenthesis would produce a valid (but different) statement. You would likely get an error (unless you were really unlucky) but it would be confusing.

@RhoSigma-QB64
Copy link
Member

To bring in another idea, _LEAVE retval would be something without collisions to other uses in QB64.

@a740g
Copy link
Contributor Author

a740g commented Oct 19, 2022

To bring in another idea, _LEAVE retval would be something without collisions to other uses in QB64.

I like this.

@SteveMcNeill
Copy link
Member

_RETVAL works for me, since RETURN is taken. It's verbose, in the spirit of BASIC, and not a ton of typing.

@RhoSigma-QB64
Copy link
Member

_RETVAL works for me, since RETURN is taken. It's verbose, in the spirit of BASIC, and not a ton of typing.

Sure, but _RETVAL would not necessarily indicate that the function will exit, just that you're willing to set a certain return value. As we look for an EXIT FUNCTION alias, it should be something which indicates that behavior.

@ghost
Copy link

ghost commented Oct 20, 2022

In my opinion, EXIT FUNCTION [return value] is the best because we have EXIT CASE, EXIT DO, EXIT WHILE, EXIT FOR, and EXIT FUNCTION

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants