$result = function(@args) would be usual syntax. You almost never need &. The main effects of & are that it passes @_ to the called function and you don't need () after the function name to pass strict. However do note that &::function and ::function are calling main::function(). This matters if you are in another package:

#package main;  # this is implicit

bar( qw( some args that were passed along ) );
foo( 'foo() stuff' );
::foo( '::foo() stuff' );
&::foo( '&::foo() stuff' );

sub bar { &foo; }
sub foo { print __PACKAGE__, " foo got '@_'\n" }

foo;  # bareword will work with no strictures after sub defn

package Foo;

foo( 'foo() stuff' );
::foo( '::foo() stuff' );
&::foo( '&::foo() stuff' );

sub foo { print __PACKAGE__, " foo got '@_'\n" }

__DATA__
main foo got 'some args that were passed along'
main foo got 'foo() stuff'
main foo got '::foo() stuff'
main foo got '&::foo() stuff'
main foo got ''
Foo foo got 'foo() stuff'
main foo got '::foo() stuff'
main foo got '&::foo() stuff'
[download]

Note that, & only passes @_ IF you leave off the parens.

So that, if bar was implemented

sub bar { &foo(); }
[download]

then it wouldn't pass anything at all to foo. So, &FUNC should be considered a different way to call than &FUNC(), because only one of them does something different than FUNC()

--
Snazzy tagline here

because only one of them does something different than FUNC()

Actually, all of them do something different as shown below:

> perl -le'@_=2;sub a($$) {shift or 1};print &a'
2
> perl -le'@_=2;sub a($$) {shift or 1};print &a()'
1
> perl -le'@_=2;sub a($$) {shift or 1};print a()'
Not enough arguments for main::a at -e line 1, at end of line
Execution of -e aborted due to compilation errors.
[download]

Sorry for the pedantry.

This question does not succumb to pedantry as much as it may appear at first glance. It is actually a very good question, and one of the nagging concerns which motivated my Subroutine Bewilderment enumerated here and here.

Although the responses were helpful, there was no systematic response regarding ampersand (&) other than basically, "you dont need to use ampersand"... and for me that's far too generic a response.

FWIW, there's at least 1 benefit for using ampersand: when you want to invoke a typographical convention that clearly distinguishes subroutine calls from barewords. (yes, I know, the parenthesis actually does that for you anyway, but as we know from Subroutine Bewilderment, parenthesis are not an absolute requirement ... at least not for brave souls who want to craft subroutines that work like the built-ins 'map' and 'grep' et al...

So this does not really answer your question, other than to suggest it is not a trifling one.

package main;

Bar::bar(\&foo);

sub foo {
  # do stuff
}

package Bar;

sub bar {
  # need to call a subroutine provided by the caller
  my $subref = shift;
  $subref->();
}
[download]

The only uses I have had for &sub are to generate subroutine references and to override subroutine prototypes.

However as others have said, if you're using functions from package A in package B, I'd strongly recommend using Exporter in package A so that package B can explicitly import the functions that it uses.

Of all the reasons to or not to &, this one, by Tilly, so that I can keep the same style in several languages. is probably the one I fall back to the most.

Most of the errors I have to deal with in cross language coding come from programming in one language, then switching to another but still using the other language's syntax (or commands).

Anything I can do to allow me to code in the language de project (working on several different ones per day) is a blessing.

That's a good idea anyway since a bare &function in Perl 6 won't call the function, but merely return a reference to the function.