Put named capture from regex in Subset into a variable in the signature

Subsignature unpacking is about turning a value into a Capture and matching against that.

class Point {
  has ( $.x, $.y );
}

my ( :$x, :$y ) := Point.new( x => 3, y => 4 ).Capture;

say "[$x,$y]"; # [3,4]

Since a Str doesn't have a public attribute named $.interesting, it won't match.

A subset is just extra code to check a value more completely than you could otherwise do. It does not turn the value into a new type.

It would be more likely to work if you used $<interesting>.

sub f( MySubset )
{
    say $<interesting>;
}

Of course since blocks get their own $/, this also does not work.

While it might be nice to pass information from a subset to a signature, I am not aware of anyway to do it.

As a side note, where already does smart matching so it is an incredibly bad idea to use ~~ inside of it.

This is basically how your subset works:

"12345678" ~~ ( * ~~ /…/ )

In this particular case you could just use .substr

sub f( MySubset $_ )    {
    .substr(1)
}

I can't figure out a way with a subset type, however there is a way - with a little...creativity - to do a match and unpack it in the signature.

Match inherits from Capture, so having one be unpacked in a signature is straightforward - if only we can arrange for there to be a parameter that contains the Match we wish to unpack. One way to do that is to introduce a further parameter with a default. We can't really stop anyone passing to it - though we can make it a pain to do so by using the anonymous named parameter. Thus, if we write this:

sub foo($value, :$ (:$col, :$row) = $value.match(/^$<col>=[<:L>+]$<row>=[\d+]$/)) {
    say $col;
    say $row;
}

And call it as foo("AB23"), the output is:

｢AB｣
｢23｣

Finally, we may factor the rule out to a named token, achieving:

‌‌my token colrow { ^$<col>=[<:L>+]$<row>=[\d+]$ }
sub foo($value, :$ (:$col, :$row) = $value.match(&colrow)) {
    say $col;
    say $row;
}

I'm pretty sure wheres (and subsets) just answer True/False. Brad concurs.

There are essentially always metaprogramming answers to questions but I presume you don't mean that (and almost never dig that deep anyway).

So here are a couple ways to get something approaching what you seem to be after.

A (dubious due to MONKEYing) solution based on Brad's insights:

use MONKEY;
augment class Str {
  method MyMatch { self ~~ / ^ \d $<interesting> = ( \d+ ) $ / }
}

class MyMatch is Match {}

sub f( MyMatch() $foo (:$interesting) ) { say ~$interesting }

f( "12345678" ); # 2345678

The bad news is that the sub dispatch works even if the string doesn't match. The doc makes it clear that the coercer method (method MyMatch in the above) cannot currently signal failure:

The method is assumed to return the correct type — no additional checks on the result are currently performed.

One can hope that one day augmenting a class will be an officially respectable thing to do (rather than requiring a use MONKEY...) and that coercing can signal failure. At that point I think this might be a decent solution.

A variant on the above that binds to $/ so you can use $<interesting>:

use MONKEY;
augment class Str {
  method MyMatch { self ~~ / ^ \d $<interesting> = ( \d+ ) $ / }
}

class MyMatch is Match {}

sub f( MyMatch() $/ ) { say ~$<interesting> }

f( "12345678" ); # 2345678

Another way that avoids MONKEYing around is to use a subset as you suggest but separate the regex and subset:

my regex Regex { ^ \d $<interesting> = ( \d+ ) $ }
subset Subset of Str where &Regex;

sub f( Subset $foo ; $interesting = ~($foo ~~ &Regex)<interesting> )
{
    say $interesting;
}

f( "12345678" ); # 2345678

Notes:

• The regex parses the input value at least twice. First in the Subset to decide whether the call dispatches to the sub. But the result of the match is thrown away -- the value arrives as a string. Then the regex matches again so the match can be deconstructed. With current Rakudo, if the sub were a multi, it would be even worse -- the regex would be used three times because Rakudo currently does both a trial bind as part of deciding which multi to match, and then does another bind for the actual call.

• Parameters can be set to values based on previous parameters. I've done that with $interesting. A signature can have parameters that are part of dispatch decisions, and others that are not. These are separated by a semi-colon. I've combined these two features to create another variable, thinking you might think that a positive thing. Your comment suggest you don't, which is more than reasonable. :)