-
Notifications
You must be signed in to change notification settings - Fork 8
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
Comments
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
'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. Ifreturn
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) becausereturn
consumes everything until the last closing parenthesis.One way or another return needs to be special. Some options are:
return
as a stand-alone statement with a pair of top-level parenthesis around arguments.(
package
keyword is not allowed in expressions, so it seems there is precedent for stand-alone statement operators like this already).return
as a stand-alone statement, but accept full syntax:return
in any way:The text was updated successfully, but these errors were encountered: