Skip Menu |

This queue is for tickets about the Moops CPAN distribution.

Report information
The Basics
Id: 100061
Status: open
Priority: 0/
Queue: Moops

People
Owner: Nobody in particular
Requestors: sven.schober [...] uni-ulm.de
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Inconsistent type constraint checking behaviour with optional, named parameter
Date: Wed, 05 Nov 2014 16:09:27 +0100
To: bug-Moops [...] rt.cpan.org
From: Sven Schober <sven.schober [...] uni-ulm.de>
Hi! I stumbled across the following today and just wanted to check, if this is expected behaviour: #!/usr/bin/env perl use Modern::Perl '2014'; use Moops; use Test::More; use Test::Exception; class cPickyConstructor { method BUILD ( Str :$x, Str :$y? ){ } fun okFunction ( Str :$x, Str :$y? ){ } }; class cNotSoPickyConstructor { method BUILD ( Str :$x, Str|Undef :$y? ){ } }; dies_ok( sub { cPickyConstructor->new( x => "", y => undef) }, 'Constructor complains about `undef` not satisfying `Str`' ); lives_ok( sub{ cPickyConstructor::okFunction( x => "", y => undef) }, 'But function does not care' ); lives_ok( sub { cNotSoPickyConstructor->new( x => "", y => undef) }, 'Need to explicitly specify `Undef` as type constraint in constructor' ); done_testing(); Cheers, Sven
Download smime.p7s
application/pkcs7-signature 4.6k

Message body not shown because it is not plain text.

The behaviour of the constructor is correct. Not quite sure why the function is allowing undef here. The difference seems to depend on whether named parameters are passed as a flattened hash or a hashref: cPickyConstructor::okFunction( x => "", y => undef ); # lives cPickyConstructor::okFunction({ x => "", y => undef }); # dies