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
Remove magic $/ shortcuts %() and @() #6287
Comments
From @briandfoyIt looks like %() with no characters between the parens creates a my %hash = %(); my $hash-empty = %(); my $hash-space = %( ); Where is %() documented (other than examples using it)? $ perl6 -v |
From @lizmat
FWIW, I have not been able to reproduce it, not on 2017.04.3 or HEAD or even 2015.12. So I find all of this rather strange :-) |
The RT System itself - Status changed from 'new' to 'open' |
From @zoffixznetOn Sun, 28 May 2017 11:56:51 -0700, comdog wrote:
Failing to reproduce this on any of the versions, including the one mentioned in OP. Is this being run in REPL? Do you have some modules loaded? (if in REPL, do you have Readline or Linenoise installed?) |
From @raiphThe token `%()` isn't an empty hash, it's a synonym for `%$/` or `$/.hash`. 'foo' ~~ /$<bar>=.*/; say %(); # Map.new((:bar(Match.new... Similarly, `@()` is a synonym for `@$/` or `$/.list`. These tokens are documented at https://docs.perl6.org/language/variables#index-entry-variable_%24%3Cnamed%3E-variable_%2525%28%29-Named_Attributes If there hasn't been significant adoption of these tokens in extant code then I'd personally +1 deprecation of them in v6.d in favor of `%$/` and `@$/`. |
From @zoffixznetOn Sun, 28 May 2017 18:18:14 -0700, raiph wrote:
+1. Even knowing I listed removal as a proposal in 6.d doc: https://github.com/perl6/specs/blob/master/v6d.pod Renaming this ticket to @LARRY/6.d RFC |
From @briandfoyI did pull my first example out of a slightly larger program I was 'abcdef' ~~ m/ cd /; my $thingy = %(); |
From @lizmat
Well, do we consider the named matches of a match modifiable or not? Feels to me having it as an (immutable) Map feels actually closer to the intent, rather than it being a (modifiable) Hash. It also gives more opportunity for optimization. So perhaps the Hashes should be considered the odd ones out? Liz |
From @AlexDanielFurther discussion on rakudo/rakudo#1946 On 2017-05-28 21:20:08, cpan@zoffix.com wrote:
|
@AlexDaniel - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#131392 (status was 'resolved')
Searchable as RT131392$
The text was updated successfully, but these errors were encountered: