in reply to why doesn't "my ($a,$b)" return a list?

Prototypes are not function parameters; rather they alter parsing.

Which is why it doesn't matter what an expression returns - it only matters how its parsed. For example a sub that returns a list doesn't work either in your example: 

$ perl -we 'sub list { 1, 2}; sub enum(\@$$) { }; enum my @a, list()'
Not enough arguments for main::enum at -e line 1, at EOF
Execution of -e aborted due to compilation errors.

[download]

Perl sees the comma operator as returning a list in this context, while it assumes that a a variable declarator returns an item.

Perl 6 - links to (nearly) everything that is Perl 6.

Replies are listed 'Best First'.
Re^2: why doesn't "my ($a,$b)" return a list?
by LanX (Saint) on Aug 19, 2010 at 14:44 UTC
    My point was that my, our and state aren't subs but operators and shouldn't be handled as subs.

    The problem stays even without prototypes.

    Anyway I think I found the answer, my returns the number of initialized variables, see the update in the OP.

    Cheers Rolf

[reply]
[d/l]
      The problem stays even without prototypes.

      Really? With a better prototype: 

      $ perl -wE 'sub list { 1, 2}; sub enum(\@@) { @_[1,2] = (1, 2)}; enum 
+my @a, state ($x, $y); say $x, $y'
12

      [download]

      Or with no prototype: 

      $ perl -wE 'sub list { 1, 2}; sub enum { @_[0,1] = (1, 2)}; enum my @a
+, state ($x, $y); say $x, $y'
12

      [download]

      To me this looks like the scalar context from the prototype was the problem - our maybe you meant a different problem? If so, care to elaborate?

      Perl 6 - links to (nearly) everything that is Perl 6.
[reply]
[d/l]
[select]
        yes sorry your right, I misintepreted the results of my tests, confusing the size of @_ with the value of the first parameter.

        I just realized in the meantime that this works: 

          DB<22> sub tst3(\@;@) {print scalar @_}
 
  DB<23> use feature 'state'; tst3 @a, state ($x,$y)
3

        [download]
        Thanks :)

        Cheers Rolf

[reply]
[d/l]

      My point was that my, our and state aren't subs but operators and shouldn't be handled as subs.

      The named operators (my, print, substr, time, etc) are just like subs in many regards, to the point of being called (builtin) functions.

      my happens to have a compile-time effect, but it still behaves like a sub at run-time.

[reply]
[d/l]
[select]
        It might be handy and orthogonal to implement my as a function, but I dare to question this design decision.

        I can't possibly imagine any use of calling my in scalar context, since the list must be statically fixed at compile time.

        Furthermore it's not intuitive, if shortening the number of my's result in these side effects. I searched for an hour to find the problem...

        Perl already has the disadvantage to default to global vars while other languages automatically restrict to a local scope without extra operator...

        ... one shouldn't be punished for trying to economize keystrokes!

        Anyway it's too late... but IMHO at least a warning should be emitted when using a my(LIST) in scalar context.

        Cheers Rolf

[reply]
[d/l]
        Well, my behaves different in several aspect to other buildins. For instance, it doesn't gobble up its arguments if there are no parens - but it does when there are. It also doesn't flatten its argument list. It also doesn't take just any expression as arguments, even though perldoc -f my suggests it does.

        I find consider my to behave like a sub quite a stretch of my imagination.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom