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

end-of-line curlies followed by operator on next line #5337

Closed
p6rt opened this issue May 27, 2016 · 4 comments
Closed

end-of-line curlies followed by operator on next line #5337

p6rt opened this issue May 27, 2016 · 4 comments
Labels
LTA Less Than Awesome; typically an error message that could be better

Comments

@p6rt
Copy link

p6rt commented May 27, 2016

Migrated from rt.perl.org#128259 (status was 'rejected')

Searchable as RT128259$

@p6rt
Copy link
Author

p6rt commented May 27, 2016

From @zoffixznet

Not sure if something easy can be done to make this code work or at least improve the error message​:

  say try { 42 }
  // 42;

Right now it fails with​:

  ===SORRY!=== Error while compiling /home/zoffix/CPANPRC/Terminal-Width/examples/term-width.p6
  Null regex not allowed
  at /home/zoffix/CPANPRC/Terminal-Width/examples/term-width.p6​:3
  ------> //⏏ 42;

Avoiding the curlies or using unspace on the previous line makes it work.

@p6rt
Copy link
Author

p6rt commented May 29, 2016

From @smls

The fact that this fails to compile is not a bug, and has nothing to do with the `//` operator.
It's because of the following Perl 6 syntax rule​:

  If the closing curly brace of a block occurs as the last thing
  in a line (not counting whitespace), then it also terminates
  its parent statement (i.e. a semicolon is implicitly assumed
  after it).

Some examples​:

  for @​foo {
  ...
  }

  @​foo.map​: {
  ...
  } # Without the rule, this would need a semicolon

  try {
  ...
  }

  custom-function {
  ...
  } # Without the rule, this would need a semicolon

In other words, the rule makes sure that you don't have to worry about what counts as a special block statement, and what is merely a normal function/method call ending with a block. You can safely skip the semicolon for *all* of them.

make this code work

Not gonna happen - or at least I'm pretty sure it won't. People have already suggested adding exceptions to the aforementioned rule for other cases where it gets in the way (e.g. in `==>` feed operator chains), but were always rejected by the powers that be.

or at
least improve the error message

I suppose it might be possible to make it so that if an invalid token is encountered in term position, the error handler checks if it immediately follows an end-of-line closing brace, and if so whether the token could match in operator position instead. This would allow it to offer a helpful suggestion in the error message.

(I'm changing the title of the RT accordingly.)

@p6rt
Copy link
Author

p6rt commented May 29, 2016

The RT System itself - Status changed from 'new' to 'open'

@p6rt p6rt closed this as completed Jun 15, 2016
@p6rt
Copy link
Author

p6rt commented Jun 15, 2016

@zoffixznet - Status changed from 'open' to 'rejected'

@p6rt p6rt added the LTA Less Than Awesome; typically an error message that could be better label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
LTA Less Than Awesome; typically an error message that could be better
Projects
None yet
Development

No branches or pull requests

1 participant