Re^2: What's so bad about &function(...)?

Another reason it doesn't much matter is that, to make things more consistent, we're changing what it means in Perl 6. The notation no longer has anything to do with how the arguments are processed--there are now flattening operators for that. Instead, when you say &foo, you're explicitly marking "foo" as a noun rather than a verb. As a noun, it always returns a scalar reference in scalar context, and like any other reference, it is not dereferenced unless you do so explicitly. In the case of &foo, it is not called unless you say &foo() or some such.

Interestingly, this completely removes the Perl 5 distinction between foo(1,2,3) and &foo(1,2,3). Those are handled identically in Perl 6. What changes is the meaning of bare &foo. You now always have to pass @_ explicitly if that's what you mean.

Comment on Re^2: What's so bad about &function(...)?

Replies are listed 'Best First'.
Re^3: What's so bad about &function(...)? by Perl Mouse (Chaplain) on Dec 09, 2005 at 22:46 UTC
In Perl5, if you have arguments to a function, the parenthesis are optional if you don't use the & sigil (unless of course they are needed to prevent misparsing). However, if you use `&foo` to call a sub, and you want to call it with arguments, the parenthesis are mandatory. Will you be able to do: `&foo 1, 2, 3` [download] in Perl6? `Perl --((8:>*`	[reply] [d/l]
Re^4: What's so bad about &function(...)? by TimToady (Parson) on Dec 10, 2005 at 00:02 UTC
Nope, Perl 6 still has to be picky about when it is expecting a term and when it is expecting an operator. It's vaguely possible we could allow `&foo: 1, 2, 3` [download] however, since there are already other cases where a colon allows us to omit the parens. Can't say it's high on my list of priorities though.	[reply] [d/l]