From @masak

<masak> std​: &foo
<p6eval> std 29829​: OUTPUT«ok 00​:01 109m␤»
<masak> rakudo​: &foo
<p6eval> rakudo 59c65b​: OUTPUT«Symbol '&foo' not predeclared [...]
<masak> alpha​: &foo
<p6eval> alpha 30e0ed​: ( no output )
* masak submits rakudobug
<masak> proof of a regression in three simple steps :)

From @pmichaud

Now fixed in 4ab4b8. Now reports​:

&foo
Could not find non-existent sub &foo

Unlike the previous error message, this is a runtime error (that occurs
when the program attempts to access &foo and cannot find one). A test​:

say &foo; { our sub foo() { 1 } }
foo

Pm

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

From @masak

On Fri Feb 26 21​:02​:28 2010, pmichaud wrote​:

Now fixed in 4ab4b8. Now reports​:

&foo
Could not find non-existent sub &foo

Unlike the previous error message, this is a runtime error (that occurs
when the program attempts to access &foo and cannot find one).

It's still quite distinct from what alpha did, namely to return a Failure
when it didn't find a subroutine.

$ alpha -e 'say &foo.WHAT'
Failure()

Which behaviour is the correct one? Is this spec'd?

From @pmichaud

On Sat, Feb 27, 2010 at 02​:38​:29AM -0800, Carl Mäsak via RT wrote​:

Unlike the previous error message, this is a runtime error (that occurs
when the program attempts to access &foo and cannot find one).

It's still quite distinct from what alpha did, namely to return a Failure
when it didn't find a subroutine.

$ alpha -e 'say &foo.WHAT'
Failure()

Which behaviour is the correct one? Is this spec'd?

I'm not sure the desired behavior is spec'd yet. When it is,
we can update rakudo to match. :-)

Pm

From @moritz

I refuse ownership of this ticket because I have no idea how to write a
test for an unspecced feature.

From @masak

This ticket seems to have spec, spectests and implementation all blocking on each other.
Meanwhile, a bit of discussion on #perl6 reveals that STD.pm6 acutally takes a stand; it checks
whether there's a 'foo' sub declared if it encounters &foo at compile time.

Unfortunately, there's a bug in STD.pm6 such that exactly that check doesn't work at present. But
that doesn't concern this ticket; the behavior reported in this ticket is decidedly not a bug.

Rejecting ticket.

@masak - Status changed from 'open' to 'rejected'