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?

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

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.

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

I can't possibly imagine any use of calling my in scalar context

if (my $x = ...) { ... }
open(my $fh, ...)
read(..., my $buf, ...)
my $r = \my $s;
[download]

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

What language are you talking about? C, C++, Java, JavaScript and VB all require local declarations.

a warning should be emitted when using a my(LIST) in scalar context.

More precisely, my LIST with a list of more than one variables.

Because of its side-effects, my LIST could legitimately be used in scalar context. This job may be more appropriate for a linter (Perl::Critic). But since that use is rare and easy to rewrite (into something clearer), a warning could be appropriate. Feel free to create a ticket (just need to email perlbug@perl.org).

I only looked quickly, but my and friends might be the only builtins to return something of questionable use in scalar context.

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.

Well, my behaves different in several aspect to other buildins.

A lot of builtins have unique parsing rules. (print, map, sort, system, our, ...) And?

It also doesn't flatten its argument list.

I don't see how you could pass something that could be flattened.

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

Sure, typically my is typically used as a directive, but we're talking about using it inside an expression. I don't see any difference between

foo(bar(ARGS));
foo(my(ARGS));
[download]

Why do you think my should behave differently than bar?