From akb.sbc@gmail.com

  > comb "foo";
  ===SORRY!=== Error while compiling <unknown file>
  Calling comb(Str) will never work with proto signature ($,, $?)
  at <unknown file>​:1
  ------> <BOL><HERE>comb "foo";

But​:

  > "foo".comb
  (f o o)
--

*Quidquid* *latine** dictum sit, **altum* *sonatur**.*

From @lizmat

On 06 May 2016, at 04​:02, Alex Brooke (via RT) <perl6-bugs-followup@​perl.org> wrote​:

# New Ticket Created by Alex Brooke
# Please include the string​: [perl #​128077]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=128077 >

comb "foo";
===SORRY!=== Error while compiling <unknown file>
Calling comb(Str) will never work with proto signature ($,, $?)
at <unknown file>​:1
------> <BOL><HERE>comb "foo";

But​:

"foo".comb
(f o o)

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 @smls

I 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;
  say @​foo.join;

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.
But with `join`, and in the general case, it won't be possible as the multi candidates may become ambiguous.
And doing it in some cases but not other, may add confusion as lizmat pointed out.

From @masak

I 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

I guess we *could* add a
multi sub comb(Str​:D $s) { $s.comb }

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).

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 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';
  .say for comb 1, 'foo';

But with `join`, and in the general case, it won't be possible as the
multi candidates may become ambiguous.
And doing it in some cases but not other, may add confusion as lizmat
pointed out.

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 @AlexDaniel

Well, you can also use this​:

Code​:
say comb ‘foo’​:

Result​:
(f o o)

From @zoffixznet

It appears the consensus is to keep `comb` as it is. Closing.

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