Skip Menu |
Report information
Id: 126116
Status: open
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: zefram [at] fysh.org
Cc:
AdminCc:

Severity: (no value)
Tag: Bug
Platform: (no value)
Patch Status: (no value)
VM: (no value)



Subject: [BUG] native type constraint inconsistently applied
To: rakudobug [...] perl.org
Date: Sun, 20 Sep 2015 17:06:48 +0100
From: Zefram <zefram [...] fysh.org>
Download (untitled) / with headers
text/plain 1.4k
Because a type object is an (undefined) instance of that type, it can in general be stored in a variable constrained to that type. We can demonstrate this with a subroutine taking a type parameter: $ ./perl6 -e 'sub aa (Mu:U ::T) { my T $a = T; say $a; }; aa(Any); aa(Int); aa(int)' (Any) (Int) (int) But if we try to do the same thing without the indirection of the subroutine, it behaves differently on native types: $ ./perl6 -e 'my Any $a = Any; say $a; my Int $b = Int; say $b; my int $c = int; say $c' (Any) (Int) Cannot unbox a type object in block <unit> at -e:1 This indirection shouldn't make such a visible difference. Obviously there's some connection here to the specialised representation implied by the int type, and the fact that that representation can't accommodate the int type object. It's fine for the specialised representation to be used in only one of these two cases, but that should be an invisible implementation detail. Perhaps the specialised representation should only be used where the variable is constrained to *defined* ints. Another inconsistency arises in how assignment of a boxed value to the variable is treated: $ ./perl6 -e 'sub aa (Mu:U ::T) { my T $a = 3; say $a.WHAT; }; aa(Any); aa(Int); aa(int)' (Int) (Int) Type check failed in assignment to '$a'; expected 'int' but got 'Int' in sub aa at -e:1 in block <unit> at -e:1 $ ./perl6 -e 'my Any $a = 3; say $a.WHAT; my Int $b = 3; say $b.WHAT; my int $c = 3; say $c.WHAT' (Int) (Int) (Int) -zefram
Still reproducible (2017.11,HEAD(e5b660e))

On 2015-09-20 09:07:10, zefram@fysh.org wrote:
Show quoted text
> Because a type object is an (undefined) instance of that type, it can
> in general be stored in a variable constrained to that type. We can
> demonstrate this with a subroutine taking a type parameter:
>
> $ ./perl6 -e 'sub aa (Mu:U ::T) { my T $a = T; say $a; }; aa(Any);
> aa(Int); aa(int)'
> (Any)
> (Int)
> (int)
>
> But if we try to do the same thing without the indirection of the
> subroutine, it behaves differently on native types:
>
> $ ./perl6 -e 'my Any $a = Any; say $a; my Int $b = Int; say $b; my int
> $c = int; say $c'
> (Any)
> (Int)
> Cannot unbox a type object
> in block <unit> at -e:1
>
> This indirection shouldn't make such a visible difference. Obviously
> there's some connection here to the specialised representation implied
> by the int type, and the fact that that representation can't
> accommodate
> the int type object. It's fine for the specialised representation to
> be used in only one of these two cases, but that should be an
> invisible
> implementation detail. Perhaps the specialised representation should
> only be used where the variable is constrained to *defined* ints.
>
> Another inconsistency arises in how assignment of a boxed value to the
> variable is treated:
>
> $ ./perl6 -e 'sub aa (Mu:U ::T) { my T $a = 3; say $a.WHAT; };
> aa(Any); aa(Int); aa(int)'
> (Int)
> (Int)
> Type check failed in assignment to '$a'; expected 'int' but got 'Int'
> in sub aa at -e:1
> in block <unit> at -e:1
> $ ./perl6 -e 'my Any $a = 3; say $a.WHAT; my Int $b = 3; say $b.WHAT;
> my int $c = 3; say $c.WHAT'
> (Int)
> (Int)
> (Int)
>
> -zefram




This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org