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

Add compiler errors for the case of non-typechecking defaults in signatures in Rakudo #2765

Closed
p6rt opened this issue May 14, 2012 · 4 comments
Labels

Comments

@p6rt
Copy link

p6rt commented May 14, 2012

Migrated from rt.perl.org#112922 (status was 'resolved')

Searchable as RT112922$

@p6rt
Copy link
Author

p6rt commented May 14, 2012

From @masak

< masak> r​: sub foo(Bool $b = sub { False }) {}; say "alive"
<p6eval> rakudo abb8f3​: OUTPUT«alive␤»
<jnthn> r​: sub foo(Bool $b = sub { False }) {}; foo(); say "alive"
<p6eval> rakudo abb8f3​: OUTPUT«Nominal type check failed for parameter
'$b'; expected Bool but got Sub instead [...]
<jnthn> phew
<masak> :)
<masak> jnthn​: would it be possible to get a compiler warning (or even
an error) for the case of non-smartmatching defaults?
<jnthn> masak​: If you mean "non-typechecking"?
<jnthn> Then probably, yes.
<jnthn> If we know the type of the RHS, which we do in this case.
<jnthn> Guess an error is fine.
<jnthn> I mean, if it's gonna fail anyway... :)
<masak> not necessarily.
<masak> not if you always call it with the argument provided.
<masak> but it's a ticking bomb, for sure.
<masak> jnthn​: will you be helped by me submitting a TODO RT ticket 'bout it?
<masak> should I make a spec change saying that copmpilers should
explicitly check for this?
<jnthn> masak​: We don't tend to spec such things as "must". But a TODO
RT is fine.
<jnthn> Or just implement it...it's only gonna be 3 or so lines of code. :)
* masak submits TODO rakudobug, and might come around to implementing it leytur
<jnthn> (in parameter action method...you already have the
nominal_type to hand, and can see if the default has a known compile
time value, which we already consider anyway)

@p6rt
Copy link
Author

p6rt commented Jun 30, 2015

From @jnthn

On Mon May 14 05​:59​:07 2012, masak wrote​:

< masak> r​: sub foo(Bool $b = sub { False }) {}; say "alive"
<p6eval> rakudo abb8f3​: OUTPUT«alive␤»
<jnthn> r​: sub foo(Bool $b = sub { False }) {}; foo(); say "alive"
<p6eval> rakudo abb8f3​: OUTPUT«Nominal type check failed for parameter
'$b'; expected Bool but got Sub instead [...]
<jnthn> phew
<masak> :)
<masak> jnthn​: would it be possible to get a compiler warning (or even
an error) for the case of non-smartmatching defaults?
<jnthn> masak​: If you mean "non-typechecking"?
<jnthn> Then probably, yes.
<jnthn> If we know the type of the RHS, which we do in this case.
<jnthn> Guess an error is fine.
<jnthn> I mean, if it's gonna fail anyway... :)
<masak> not necessarily.
<masak> not if you always call it with the argument provided.
<masak> but it's a ticking bomb, for sure.
<masak> jnthn​: will you be helped by me submitting a TODO RT ticket
'bout it?
<masak> should I make a spec change saying that copmpilers should
explicitly check for this?
<jnthn> masak​: We don't tend to spec such things as "must". But a TODO
RT is fine.
<jnthn> Or just implement it...it's only gonna be 3 or so lines of
code. :)
* masak submits TODO rakudobug, and might come around to implementing
it leytur
<jnthn> (in parameter action method...you already have the
nominal_type to hand, and can see if the default has a known compile
time value, which we already consider anyway)

It now catches it at compile time. Test added to S06-signature/optional.t.

@p6rt
Copy link
Author

p6rt commented Jun 30, 2015

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

@p6rt
Copy link
Author

p6rt commented Jun 30, 2015

@jnthn - Status changed from 'open' to 'resolved'

@p6rt p6rt closed this as completed Jun 30, 2015
@p6rt p6rt added the Todo 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