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

return statement #1

Closed
vickenty opened this issue Jul 12, 2016 · 1 comment
Closed

return statement #1

vickenty opened this issue Jul 12, 2016 · 1 comment

Comments

@vickenty
Copy link
Collaborator

vickenty commented Jul 12, 2016

'Subroutine calls' mentions that return there is no special cases for return, but it does not seem possible.

For example:

foo(1, return(2, 3), 4);

If return is not special and treated like any other subroutine, it will be possible to use it in an expression. If return was a subroutine, it would get arguments (2, 3), so under these rules the snippet above should return (2, 3) as well. But in perl this returns (2, 3, 4) because return consumes everything until the last closing parenthesis.

One way or another return needs to be special. Some options are:

  1. only allow return as a stand-alone statement with a pair of top-level parenthesis around arguments.
return(1, 2); # ok
return(1, 2), 3; # not ok
return(@foo); # ok
return @foo; #not ok
foo(1, return 2); # not ok

(package keyword is not allowed in expressions, so it seems there is precedent for stand-alone statement operators like this already).

  1. only allow return as a stand-alone statement, but accept full syntax:
return (1, 2), 3; # ok
return @foo; # ok
foo(1, return 2) # not ok
  1. don't restrict use of return in any way:
foo(1, return 2) # ok
foo(1, return (2, 3), 4) # ok
@xsawyerx
Copy link
Owner

I think (1) is the best option and I've changed the wiki to reflect this.

Thank you! :)

xsawyerx added a commit that referenced this issue May 7, 2020
sort has multiple options:

1. sort { $a <=> $b } @foo;
2. sort @foo;
3. sort $subname @foo;
4. sort subname @foo;

Option #1, #2, and #3 are supported.
Option #3 requires explicitly a scalar variable, not an expression.
Option #4 is very odd. It explicitly wants a bareword of a sub name.

Option #4 is *NOT* supported.
xsawyerx added a commit that referenced this issue May 25, 2020
While fixing up tests, I found that we don't tell the difference between
Ident used for classes and ones used for subroutine names.

They're mostly similar, but the following is different:

1. Foo::->bar()  # method call, works
2. Foo->bar()    # same, ambiguous to perl, but not to guacamole
3. Foo::bar()    # Function call, Foo class, bar function name
4. Foo::bar::()  # Error!

But because we use Ident for all of these, #1 and #4 are getting confused.

We can fix it. It's not a top priority.
xsawyerx added a commit that referenced this issue May 27, 2020
While fixing up tests, I found that we don't tell the difference between
Ident used for classes and ones used for subroutine names.

They're mostly similar, but the following is different:

1. Foo::->bar()  # method call, works
2. Foo->bar()    # same, ambiguous to perl, but not to guacamole
3. Foo::bar()    # Function call, Foo class, bar function name
4. Foo::bar::()  # Error!

But because we use Ident for all of these, #1 and #4 are getting confused.

We can fix it. It's not a top priority.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants