Intriguing. If you quote the $1, you get the expected output. Quite what that tells us I'm not sure.

Update: this also works:

        a => ($b =~ /(\d+)/ ? 0+$1: 0),
[download]

As does this:

        a => ($b =~ /(\d+)/ ? do{ print $1; $1 }: 0),
[download]

But not this:

        a => ($b =~ /(\d+)/ ? do{ $1 }: 0),
[download]

Interesting. Similar to your +0, this seems to work:

        a => ($b =~ /(\d+)/ ? "$1" : 0),

Could this be a Perl bug?

It certainly looks that way to me.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?

The "$1" forces a copy. Or you could swap the assignment:

hash = (
        b => ($b =~ /\d/    ? 1  : 0),
        a => ($b =~ /(\d+)/ ? $1 : 0),
);
[download]

hash = (
        a => ($b =~ /(\d+)/)[0] || 0,
        b => ($b =~ /\d/    ? 1  : 0)
);
[download]

$ perl -wE 'sub f {say @_} 3 =~ /(\d)/; f $1'
3
$ perl -wE 'sub f {"1" =~ "1"; say @_} 3 =~ /(\d)/; f $1'
Use of uninitialized value $_[0] in say at -e line 1.
$ perl -wE 'sub f {"1" =~ "1"; say @_} 3 =~ /(\d)/; f "$1"'
3
$
[download]

It might be a little more obvious like this:

$b =  'test 100';

%hash = (
        a => ($b =~ /(\d+)/ ? $1 : 0),
        b => ($b =~ /(\w+)/ ? 1  : 0),
);

print "$hash{a}\n";
[download]

which prints

test
[download]

So, it did the second pattern match first, and interpreted $1 to be the result of that pattern match. It's the same sort of ambiguity that is found in, say, ($i++)+$i.

I saw the same outputs in my perl 5.12.3. It seems perl confusing for $1 because this also prints "100" without warnings;

%hash =(
  a => ($b =~ /(\d+)/ ? $1 : 0),
  b => "test b",
);
print "$_=#$hash{$_}#\n" for keys %hash;
[download]

And named capture seems to work fine.

%hash = (
  a => (($b =~ /(?<tag>\d+)/) ? $+{tag} : 0),
  b => (($b =~ /(?<tag>test)/) ? $+{tag} : 0),
);
print "$_=#$hash{$_}#\n" for keys %hash;
[download]

But I have no idea for why named capture doesn't confuse...

So, it did the second pattern match first, and interpreted $1 to be the result of that pattern match

Then why does quoting $1 'fix' it?

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?

AFAIK, the order in which these subexpressions are evaluated is not defined. Adding one more operation (more or less any operation, "" or - or sqrt all work) does change the order of evaluation. But in the absence of some rule requiring the second and third operands of ?: to be evaluated after the first one rather than before, that's merely a detail of the implementation. I don't see any rule about it offhand in "conditional operator" in perlop.

It seems match the last 'key => value' first, i try the below code serval times, but got the same output.

use strict;
use warnings;

use Data::Dumper;

my $b =  'test  200';
my %hash = (
          c => ( $b =~ /([a-z]+)/ ? $& : 0 ),
          b => ( $b =~ /(\d+)/ ? $` : 0 ),
          a => ( $b =~ /\s+/ ? $' : 0 ),
        );

print Dumper(\%hash);
[download]

Output:

$VAR1 = {
          'c' => '  ',
          'a' => '200',
          'b' => 'test'
        };
[download]