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

Make the first argument of comb optional, so that comb "foo" behaves like "foo".comb #5300

Closed
p6rt opened this issue May 6, 2016 · 9 comments
Labels
RFC Request For Comments

Comments

@p6rt
Copy link

p6rt commented May 6, 2016

Migrated from rt.perl.org#128077 (status was 'resolved')

Searchable as RT128077$

@p6rt
Copy link
Author

p6rt commented May 6, 2016

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

@p6rt
Copy link
Author

p6rt commented May 6, 2016

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

@p6rt
Copy link
Author

p6rt commented May 6, 2016

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

@p6rt
Copy link
Author

p6rt commented May 6, 2016

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.

@p6rt
Copy link
Author

p6rt commented May 6, 2016

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

@p6rt
Copy link
Author

p6rt commented May 6, 2016

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.

@p6rt
Copy link
Author

p6rt commented May 8, 2016

From @AlexDaniel

Well, you can also use this​:

Code​:
say comb ‘foo’​:

Result​:
(f o o)

@p6rt
Copy link
Author

p6rt commented Jul 9, 2016

From @zoffixznet

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

@p6rt
Copy link
Author

p6rt commented Jul 9, 2016

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

@p6rt p6rt closed this as completed Jul 9, 2016
@p6rt p6rt added the RFC Request For Comments label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
RFC Request For Comments
Projects
None yet
Development

No branches or pull requests

1 participant