Named Subroutine return values

[Joe Gottman]

According to the revised Synopsis 6, named subroutines can have one of three
forms:

my RETTYPE sub NAME ( PARAMS ) TRAITS {...} # lexical only

our RETTYPE sub NAME ( PARAMS ) TRAITS {...} # also package-scoped

sub NAME ( PARAMS ) TRAITS {...} # same as "our"

Note that the third possibility here does not include a return type. Does
this imply that if we want to declare a subroutine with a return type we
have to declare it as either a "my" sub or an "our" sub?

Joe Gottman

[Damian Conway]

Joe Gottman asked:

> my RETTYPE sub NAME ( PARAMS ) TRAITS {...} # lexical only
> our RETTYPE sub NAME ( PARAMS ) TRAITS {...} # also package-scoped
> sub NAME ( PARAMS ) TRAITS {...} # same as "our"
>
> Note that the third possibility here does not include a return type. Does
> this imply that if we want to declare a subroutine with a return type we
> have to declare it as either a "my" sub or an "our" sub?

No. One of the available TRAITS is C<returns RETTYPE>. So you can always
specify a "postfix" return type, even without a declarator:

sub data() returns Str {...}

The declarator is only needed if you want to "prefix" your return type
(presumably because you're pining for C/C++ ;-):

our Str sub data() {...}

Damian

[Luke Palmer]

On 2/24/06, Damian Conway <dam...@conway.org> wrote:
> No. One of the available TRAITS is C<returns RETTYPE>. So you can always
> specify a "postfix" return type, even without a declarator:
>
> sub data() returns Str {...}
>
> The declarator is only needed if you want to "prefix" your return type
> (presumably because you're pining for C/C++ ;-):
>
> our Str sub data() {...}

Didn't we decide that:

our Str sub foo() {...}

Was equivalent to:

our sub foo(--> Str) {...}

But not to:

our sub foo() returns Str {...}

?

Come to think of it, that seems backwards. After all, aren't:

my Foo $x;
my $x of Foo;

Equivalent?

Come to think of it, it's probably a bad idea to have a distinction at all.

Luke

[Larry Wall]

Au contraire, I think it's a good idea in the mindthink of "Be strict
in what you emit." Or maybe it's "Underpromise and overperform."
The prefix and --> forms advertise a particular promise, but the
routine might actually wish to be pickier than that on what it actually
emits, and rather than casting every return statement to a particular
type, can say "returns Str" instead.

Say, for instance, you're in a situation where the return type might
be used for a tiebreaker, but you want to reserve that "namespace"
for yourself. On the other hand, your current implementation is
perhaps TCLishly string oriented. But you want to call out to other
functions that aren't "Str filtered". You can declare

sub foo (--> Any) returns Str {
return whatever();
}

and force Str context on whatever() without promising that you're doing
that do everyone else.

Larry

[Larry Wall]

On Fri, Feb 24, 2006 at 04:56:40AM +0000, Luke Palmer wrote:

: Come to think of it, that seems backwards. After all, aren't:

:
: my Foo $x;
: my $x of Foo;
:
: Equivalent?

Didn't answer this part...

If --> and returns are different, than "of" probably sets the --> type
rather than the "returns" type. Or maybe there's no distinction
for non-subs, but it seems nice to associate "returns" with "return".

Larry