Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

native type constraint inconsistently applied #4562

Open
p6rt opened this issue Sep 20, 2015 · 3 comments
Open

native type constraint inconsistently applied #4562

p6rt opened this issue Sep 20, 2015 · 3 comments
Labels

Comments

@p6rt
Copy link

p6rt commented Sep 20, 2015

Migrated from rt.perl.org#126116 (status was 'open')

Searchable as RT126116$

@p6rt
Copy link
Author

p6rt commented Sep 20, 2015

From zefram@fysh.org

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

@p6rt
Copy link
Author

p6rt commented Dec 3, 2017

From @AlexDaniel

Still reproducible (2017.11,HEAD(e5b660e))

On 2015-09-20 09​:07​:10, zefram@​fysh.org wrote​:

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

@p6rt
Copy link
Author

p6rt commented Dec 3, 2017

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

@p6rt p6rt added the Bug label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant