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

Misleading error message when using a definite constant as type constraint #4563

Open
p6rt opened this issue Sep 20, 2015 · 3 comments
Open
Labels
LTA Less Than Awesome; typically an error message that could be better

Comments

@p6rt
Copy link

p6rt commented Sep 20, 2015

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

Searchable as RT126117$

@p6rt
Copy link
Author

p6rt commented Sep 20, 2015

From zefram@fysh.org

How nice to be able to use a constant declaration to give a local name
to a (possibly complex) type​:

$ ./perl6 -e 'constant T = Int; my T $a = 3; say $a'
3

But because the constant declaration accepts any kind of defining
expression, and gives the value a bareword name, it makes it syntactically
possible to use something other than a type object as a type constraint.
This doesn't work so well​:

$ ./perl6 -e 'constant T = 3; my T $a; say $a; $a = 3; say $a'
3
Type check failed in assignment to '$a'; expected 'Int' but got 'Int'
  in block <unit> at -e​:1

The error message on assignment is nonsensical, because the types it
complains are mismatching are identical. The only value that can be
successfully assigned is Nil, which leaves the variable holding the same
(default) value.

The same effect can be seen without the user making eir own constant
declaration by using the predefined constant i.

Presumably using a defined value (anything other than a type object)
as a type constraint should be a semantic error.

-zefram

@p6rt
Copy link
Author

p6rt commented Sep 11, 2017

From @smls

On Sun, 20 Sep 2015 09​:17​:21 -0700, zefram@​fysh.org wrote​:

Presumably using a defined value (anything other than a type object)
as a type constraint should be a semantic error.

It does throw a compile-time error for the `my` declaration now, however the error message is not appropriate​:

  ➜ constant T = 3; my T $a; say $a; $a = 3; say $a;
  ===SORRY!=== Error while compiling​:
  Variable definition of type Int (implicit : by pragma)
  requires an initializer
  ------> constant T = 3; my T $a⏏; say $a; $a = 3; say $a;
  expecting any of​:
  constraint

According to bisectable¹, this new behavior was introduced by a commit² by FROGGS in Oct 2015.

That commit implemented Type​:D and Type​:U types, and the "implicit : by pragma" part of the error message is actually meant to print something like "implicit :D by pragma", except apparently it also catches the unrelated issue of this RT.

It should be made to print a more appropriate message in this case.

Marking this as an LTA ticket.


[1] https://gist.github.com/Whateverable/a6f61fac5114f64747a8a9d913e2f3d7
[2] rakudo/rakudo@80a3d07

@p6rt
Copy link
Author

p6rt commented Sep 11, 2017

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

@p6rt p6rt added the LTA Less Than Awesome; typically an error message that could be better label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
LTA Less Than Awesome; typically an error message that could be better
Projects
None yet
Development

No branches or pull requests

1 participant