From @masak

<moritz> nom​: say ().pick.defined
<p6eval> nom 33fb02​: OUTPUT«True␤»
<moritz> nom​: say ().pick.perl
<p6eval> nom 33fb02​: OUTPUT«().list␤»
<moritz> uhm
<moritz> shouldn't that return something like Nil?
<moritz> niecza​: say ().pick.perl
<p6eval> niecza v14-20-g18249a6​: OUTPUT«Any␤»
<moritz> or that
<masak> I think I can make a stronger case for Nil than for Any.
<masak> but it depends on how much a special case .pick() is compared
to .pick($n).
<moritz> perl6​: say (1, 2).pick(3).perl
<p6eval> rakudo 33fb02, niecza v14-20-g18249a6​: OUTPUT«(2, 1).list␤»
<p6eval> ..pugs b927740​: OUTPUT«(1, 2)␤»
<moritz> perl6​: say ().roll.perl
<p6eval> niecza v14-20-g18249a6​: OUTPUT«Any␤»
<p6eval> ..rakudo 33fb02​: OUTPUT«Nil␤»
<masak> nom​: say ().pick.defined; say ().roll.defined
<p6eval> nom 33fb02​: OUTPUT«True␤False␤»
<masak> yeah. not kosher.
* masak submits rakuodbug

Clearly, something is underspecified/incorrect in all this. .pick and
.roll should behave the same on empty lists, and there should be a
good rationale for what it returns.

Here's what S02 has to say about Nil​:

  There is a special C<Parcel> value named C<Nil>. It means "there
  is no value here". It is the undefined equivalent of the empty
  C<()> list, except that the latter is defined and means "there are
  0 arguments here".

So Nil sounds like a fine candidate for ().pick to return, in the
sense that calling .pick indicates the expectation to get a value
back, but there is no value there.

From @moritz

Fixed in 925e3cd and tested in S32-lists/{pick,roll}.t

@moritz - Status changed from 'new' to 'resolved'