Patrick R. Michaud wrote:
> t/spec/S02-builtin_data_types/type.t:23 in the spectests (r20685)
> has the following:
>
> my Int $foo;
> my Str $bar;
>
> #?rakudo skip 'type checking unimpl'
> {
> #?pugs 1 todo
> is(try{$foo = 'xyz'}, undef, 'Int restricts to integers');
> is(try{$foo = 42}, 42, 'Int is an integer');
>
> #?pugs 1 todo
> is(try{$bar = 42}, undef, 'Str restricts to strings');
> is(try{$bar = 'xyz'}, 'xyz', 'Str is a strings');
> }
>
> However, statement_prefix:try is defined as (STD.pm:2749)
>
> token statement_prefix:try { <sym> <.ws> <statement> {*} }
>
> Thus <statement> subrule of the try statement ends up consuming all
> of the arguments that were intended for C<is>. In other words,
> it's parsing the C<try> statements as:
>
> try {$foo = 'xyz'}, undef, 'Int restricts to integers'
> try {$foo = 42}, 42, 'Int restricts to integers'
> ...
>
> Anyone have comments or suggestions about how we might fix the
> test or correct the grammar?
The ad-hoc fix of the test are parenthesis, I guess.
But I think that these tests should be rewritten in terms of
eval_lives_ok and eval_dies_ok (or just the latter), because a clever
compiler could prove at compile time that there will be a type clash,
and bail out early. The test at it is currently formulated forbids that.
So I would write these tests as follows:
eval_dies_ok '$foo = "xyz"', "Int restricts to Integers";
{
$foo = 42;
is $foo, 42, 'Int allows assignment of integers';
}
the extra pair of curlies around the second tests allow easy fudging if
the test should fail. That could be considered prematurely pessimistic,
so it's up to personal style.
Cheers,
Moritz
