While the former thought experiment was closer to Python's behavior - all vars belong (mostly) to function scope - there is another possible approach.

1. any assignment to a new variable leads to an implicit my but only if their was no previous explicit declaration in a surrounding scope. This will replace former rules 1,4 and 5 all others still apply

Hence we get the following 4 cases for explicit declarations with my or our

automine effect comment 
{ 
    $x = 1;
    {
        $x = 2;
    }
}

[download]
 
{ 
    my $x = 1;
    {
        my $x = 2;
    }
}

[download]
 not strict w/o automine 
{ 
    $x = 1;
    {
        my $x = 2;
    }
}

[download]
 
{ 
    my $x = 1;
    {
        my $x = 2;
    }
}

[download]
 not strict w/o automine 
{ 
    my $x = 1;
    {
        $x = 2;
    }
}

[download]
 
{ 
    my $x = 1;
    {
        $x = 2;
    }
}

[download]
 backwards compatible 
{ 
    my $x = 1;
    {
        my $x = 2;
    }
}

[download]
 
{ 
    my $x = 1;
    {
        my $x = 2;
    }
}

[download]
 backwards compatible

Surprises and pitfalls:

automine effect comment 
sub foo { 
    if (1) {
        $x = 2;
    }
    print $x;
}

[download]
 
sub foo { 
    if (1) {
        my $x = 2;
    }
    print $x;     # undeclared
}

[download]
 Doesn't compile

Surprising for Pythonistas 

sub add { 
    $x = 0;
    for (1..9) {
        $x = $x + $_;
    }
    print $x;
}

[download]
 
sub add { 
    my $x = 0;
    for (1..9) {
        my $x = $x + $_;
    }
    print $x;         # prints 0
}

[download]
 Unexpected result!

Needs an explicit my $x = 0 at init to avoid implicit my

This is a very Perlish approach and avoids many edge cases.

Of course this laziness comes with a price, introducing a new explicit declaration on file scope has an effect at the distance and could silently break subroutines

use automine
# our $var;

... 

sub foo {
    $var = shift; # not 'my $var' if explicit 'our $var' exists 
    ...
}

[download]

That's why this theoretical pragma must be optional. (Of course scoping the our inside a tight block would also prevent this.)

Cheers Rolf
(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery

In reply to Re^5: A short whishlist of Perl5 improvements leaping to Perl7 (Thought Experiment No.2) by LanX
in thread A short whishlist of Perl5 improvements leaping to Perl7 by rsFalse

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.