-
Notifications
You must be signed in to change notification settings - Fork 1
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
Make the first argument of comb
optional, so that comb "foo"
behaves like "foo".comb
#5300
Comments
From akb.sbc@gmail.com > comb "foo"; But: > "foo".comb *Quidquid* *latine** dictum sit, **altum* *sonatur**.* |
From @lizmat
Not sure this qualifies as a bug. The first parameter to the “sub comb” is always the matcher. In the method case, this is also the first parameter and can be easily omitted, because the object is clearly the string to be worked on. I guess we *could* add a multi sub comb(Str:D $s) { $s.comb } but it feels to me this is too much DWIM, and very close to a WAT? Please note that you can also say: comb 1,”foo” to get the desired result. Liz |
The RT System itself - Status changed from 'new' to 'open' |
From @smlsI agree with lizmat: It's not a bug, but could potentially be an [RFC]. It's similar to how the function form of `join` requires a separator as its first argument, whereas in the method form you can leave it off to use the default separator of the empty string: say join '', @foo; The reason is that a parameter can only have a default value (and therefore be optional) if it is not followed by another non-optional argument. In the case of .comb, an optional $matcher parameter before a mandatory $input parameter could be using a multi candidate. |
From @masakI agree; what's being proposed is tantamount to adding an optional parameter before a mandatory one. This is true even if it's expressed as multis. It's generally considered questionable design to have optional parameters before mandatory ones. (Which is why Perl 6 doesn't allow that in a single signature.) |
From @zoffixznet
FWIW, last night I did it with: multi sub comb(Cool $input) { $input.Str.comb() } There were some spectest failures though that looked unrelated to the change (I'm unsure if they were present before my change).
To me, it doesn't feel like a WAT. In fact, comb 1, "foo" looks weird and I'd have to pause on that while reading it, while plain comb reads well. Consider: .say for comb 'foo';
The case of join() is a technological limitation and it's easy to explain/understand why the joiner is not optional. The case of comb is simply an unimplemented feature and the inconsistency between sub/method form already caused confusion, hence the creation of the ticket. The sub/method forms of comb are more closely related to each other than sub comb/sub join, which is why IMO maintaining consistency between sub/method form is more important than between comb/join. |
From @AlexDanielWell, you can also use this: Code: Result: |
From @zoffixznetIt appears the consensus is to keep `comb` as it is. Closing. |
@zoffixznet - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#128077 (status was 'resolved')
Searchable as RT128077$
The text was updated successfully, but these errors were encountered: