# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #123919]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org/Ticket/Display.html?id=123919 >
<masak> m: sub bar($a, $b) {}; bar(1)
<camelia> rakudo-moar 546000: OUTPUT«===SORRY!=== Error while
compiling [...]Calling 'bar' will never work with argument types
(int) Expected: :(Any $a, Any $b) [...]
<masak> m: sub bar($a, $b) {}; my $x = 1; bar($x)
<camelia> rakudo-moar 546000: OUTPUT«Too few positionals passed;
expected 2 arguments but got 1 [...]
<masak> why is the first a compile-time error and the second a runtime error?
<PerlJam> at a guess, because 1 is a compile-time constant and $x isn't.
<jnthn> What PerlJam said, basically.
<jnthn> The errors fall out of inlining efforts.
<jnthn> And the inlining stuff cares a bunch about types.
<masak> is there any situation where `bar($x)` can mean anything other
than "pass one argument"?
<jnthn> No
<jnthn> It's not that we can't catch that one at compile time
<jnthn> It's simply that we catch them as a side-effect of
optimization, and in this case we're apparently not trying to
optimize.
<Kristien> ew
<jnthn> The promise is "runtime at latest, compile time preferable"
<masak> right.
<masak> so it's not a *bug* in the sense that it's failing to do
something we promised...
<jnthn> Correct, but it's disappointing still. :)
<masak> it's more of an LTA because it's a case where we could be more
awesome, but aren't at present.
* masak submits LTA rakudobug :)
<PerlJam> masak++ (I was just about to encourage you to do that :)
<jnthn> Key thing to understand here is that the static inliner
laregly exists to make sure we generate nice code for native
operators.
<jnthn> Anything beyond that is, so far, as bonus.
<jnthn> Again, we'll get better at it.
<jnthn> And yes, I'm fine with an LTA ticket.
<jnthn> May even look at it soonish, as I need to pay a visit to the
optimizer while dealing with native refs.
<masak> \o/
<masak> I think the architecture we have is great, so don't take this
the wrong way: we shouldn't be limited by an argument such as "there's
no compile-time error here about this impossible situation, because
we're not attempting to inline it"
<jnthn> True, though we shouldn't duplicately implement tricky logic either
<jnthn> I think the place we're doing the analysis is right, but we
probably shouldn't give up trying so easily
<masak> ok, fairy nuff.
