Skip Menu |
Report information
Id: 125438
Status: new
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: bri [at] abrij.org
Cc:
AdminCc:

Severity: (no value)
Tag: (no value)
Platform: (no value)
Patch Status: (no value)
VM: (no value)



From: bri <bri [...] abrij.org>
To: rakudobug [...] perl.org
Subject: Extra parameters not ACCEPTed when smartmatching sig with invocant
Date: Fri, 19 Jun 2015 01:52:40 -0400
Download (untitled) / with headers
text/plain 547b
# Should a methodlike Signature ACCEPT extra named parameters? # First, this is at least an LTA error but arguably should be True bri@atlas:~/NetSight/pm6$ perl6 -e 'say so (1,2) ~~ :($a: $b)' Lexical with name 'self' does not exist in this frame in block <unit> at -e:1 # So just to establish this workaround works first... bri@atlas:~/NetSight/pm6$ perl6 -e 'say so (1,2) ~~ :(\self: $b)' True # ...and now we see that a methodlike signature rejects extra nameds: bri@atlas:~/NetSight/pm6$ perl6 -e 'say so (1,2,:a) ~~ :(\self: $b)' False
Download (untitled) / with headers
text/plain 902b
This has sort of been swept under the rug by making it difficult to make a signature literal with an invocant. $ perl6 -e 'say so (1,2) ~~ :(\self: $b)' ===SORRY!=== Error while compiling -e Can only use the : invocant marker in the signature for a method at -e:1 ------> say so (1,2) ~~ :(\self: $b⏏) expecting any of: constraint There may eventually be a reason to do that, but for now it keeps anyone from relying on the behavior there. In the meantime we've made method signatures show the %*_ $ perl6 -e 'class foo { method bar (Any: $b) { } }; my $s = foo.^find_method("bar").signature; $s .= clone; $s.perl.say; say so (1, 2, :a) ~~ $s' :($: $b, *%_) True Perhaps were we to ever allow methodish signature literals, we could say it is the "method" declaration (or something in ClassHOW's handling of them, really) that adds the *%_, and one has to add it explicitly in a :()


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org