From @masak

<masak> rakudo​: sub foo { return }; say foo.WHAT; say ?(foo ~~ Nil)
<p6eval> rakudo 5b1ff9​: OUTPUT«Nil␤0␤»
* masak submits

Expected behavior​: a "Nil" and a 1. Or an explanation about why a
value shouldn't smartmatch successfully against its own type.

From @kyleha

On Sun Mar 15 08​:36​:42 2009, masak wrote​:

Expected behavior​: a "Nil" and a 1. Or an explanation about why a
value shouldn't smartmatch successfully against its own type.

<pmichaud> KyleHa​: n ~~ Nil is the same as n( ~( ~Nil ) )
<KyleHa> pmichaud​: Is that how it should be or just how it is right now?
<pmichaud> Well, unless we special-case prefix;<~~> to do something
else, that's "how it should be"
<pmichaud> i.e., it's the same as n ~ ~ Nil

I wrote tests for this behavior in S02-builtin_data_types/nil.t

From @pmichaud

On Sun Mar 15 08​:36​:42 2009, masak wrote​:

<masak> rakudo​: sub foo { return }; say foo.WHAT; say ?(foo ~~ Nil)
<p6eval> rakudo 5b1ff9​: OUTPUT«Nil␤0␤»
* masak submits

Expected behavior​: a "Nil" and a 1. Or an explanation about why a
value shouldn't smartmatch successfully against its own type.

Note that "foo ~~ Nil" is the same as "foo(~~Nil)" which is the same as
"foo(~(Nil))". In other words, it's not a smartmatch operator here,
it's two prefix​:<>s.

Rejecting ticket.

Pm

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

@pmichaud - Status changed from 'open' to 'rejected'

From @kyleha

This is an automatically generated mail to inform you that tests are now available in b/t/spec/S02-builtin_data_types/nil.t