From @bbkr

$ perl6 -e 'sub foo ( :$id? where { say "I should not be here when there is no
param passed"} ) {}; foo()'

Returns​:
I should not be here when there is no param passed

$ perl6 --version
This is perl6 version 2012.01 built on parrot 3.11.0 revision RELEASE_3_11_0

From @masak

On Fri Jan 27 02​:21​:32 2012, pawel.pabian@​implix.com wrote​:

$ perl6 -e 'sub foo ( :$id? where { say "I should not be here when
there is no
param passed"} ) {}; foo()'

Returns​:
I should not be here when there is no param passed

$ perl6 --version
This is perl6 version 2012.01 built on parrot 3.11.0 revision
RELEASE_3_11_0

<masak> nom​: sub foo($x? where { .defined }) { say "OH HAI" }; foo
<p6eval> nom 6eae67​: OUTPUT«Constraint type check failed for parameter
'$x' [...]
<masak> what say you? should the above run the where clause or not?
<jnthn> masak​: I was dubious about that ticket.
<moritz> masak​: it's wrong
<jnthn> masak​: We used to have a bug where we didn't type check default
values.
<moritz> type checks also apply to defaults
<jnthn> Right
<jnthn> Yeah, I think the ticket is wrong.
<moritz> and optional params are just some weird kind of automatic
undefined default
<jnthn> It's not so hard to imagine a where condition that matches on
undefined and defined values.
* masak rejects ticket

A case can be made for either behavior (don't where-check not provided
variables, type-check provided variables), but I think Perl 6 is
converging on semantics where parameters that don't get passed are very
similar to uninitialized variables. From the perspective of the callee,
it shouldn't matter whether an argument wasn't passed, or whether it was
passed in some undefined form.

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

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