On Tue, Jun 06, 2006 at 05:11:26PM +0100, Daniel Hulme wrote:
: I only vaguely recall the discussions a while back about what
: smart-matching against Booleans should do. IIRC, there are two
: positions, and a good argument for either side:
: C<$foo ~~ True> means C<?$foo>; C<$foo ~~ False> means C<! ?$foo>
: or
: C<$foo ~~ True> means C<True>; C<$foo ~~ False> means C<False>
: The first of these adds expressiveness to given/when, and behaves the
: intuitive way when both the RHS of a match is a Boolean-valued variable
: (I would intuitively expect C<$bool1 ~~ $bool2> to do Boolean equality).
: The second means that the default case of a while can be syntactic sugar
: for C<when (true)>, and I see that we went for the latter on those
: grounds.

Actually, those grounds were only part of it.  It was also for the
notational convenience of treating C<when> as having C<if> semantics
in some cases, except for the breaking out of the switch at the end
of the block.

However, C<when true> in S04 is now actually illegal syntax.
It'd have to be either C<when .true> or C<when True>.  (Or C<when *>
if we decide to make Whatever mean that in that context.)

: However, if we make the Whatever star on the RHS always match, we can
: make C<default> equivalent to C<when (*)>, reminiscently of a shell
: script, and we can also make C<$bool1 ~~ $bool2> do the obvious thing.
: I don't immediately see any big wins for being able to say C<$foo ~~ *>,
: nor any big loses for it no longer falling through to MMD.
: Any thoughts?

We could conceivably make C<when *> behave that way regardless of
how C<when True> behaves.  It'd be equivalent to C<when {1}> then.
But maybe Whatever isn't symmetrical under smartmatching--I could
imagine using C<given *> to be shorthand for C<given {.true}>, that
is, forcing the C<when> expressions to behave like C<if> conditionals.

The thing I worry about is that when someone writes

    given $foo {
        when $a == $b {...}

they probably don't mean ?$foo == ($a == $b).  Whereas when they write

    given $foo {
        when True {...}

they might well mean ?$foo == True.

We could say that boolean comparison happens only if both sides are
exactly equal to the Bool type.  So if $foo above isn't a Bool, then
you'd have to be explicit in the given:

    given ?$foo {
        when True {...}

in which case it would compare boolean values.  Likewise

    given ?$foo {
        when $a == $b {...}

would compare the boolean value of $foo with the result of the ==.

Or going the other way, we could risk confusing the writer of

        when $a == $b {...}

by requiring that to be written:

        when {$a == $b} {...}

to explicitly ignore $_ (unless $_ happened to be Whatever).  But then
we'd probably have to make smartmatch with a boolean on only one side
completely illegal.

Whatever we do, we need to make sure

    given $enum {
        when Foo {...}
        when Bar {...}
        when Baz {...}

works as expected.  So that tends to argue that

    given $bool {
        when False {...}
        when True {...}

should work that way, on the assumption that Bool is just an enum.
But Bool is really a role, and basically any type does Bool.  So that
tends to argue for either comparing $a == $b to $bool or illegalifying
it somehow when ambiguous.


Reply via email to