my $sql = q{...};
        ...do some DB stuff...
        my $sql = q{...};
        ...do more DB stuff...

This of course results in re-defining $sql, so I take out the second
"my", but then at some point I remove the first one, and strict chews me
out over not declaring $sql, so I make it "my" again.

This is a cycle I've repeated with dozens of variations on more
occasions than I care to (could?) count.

What I'd really like to say is:

        throwawaytmpvar $sql = q{...};
        throwawaytmpvar $sql = q{...};

without problems. Of course, "throwawaytmpvar" is a bit long, but you
get the idea.

It should probably be illegal to:

        throwawaytmpvar $sql = q{...};
        my $sql = q{...}; # Error: temporary became normal lexical

or for that matter even give it a new type:

        throwawaytmpvar int $i = 0;
        throwawaytmpvar str $i = "oops"; # Error: redefinition of type

There might be other assumptions that this implies. For example, it
might be considered always thread-private and might be required to be a
core, unboxed type. These extra assumptions are only worth it if they
enhance the optimization possibilities surrounding such a value.

And at that point, why not just change it to this?

        my $sql;
        $sql = q{...};
        ...do some DB stuff...
        $sql = q{...};
        ...do more DB stuff...

It seems to me that assignment does a pretty good job of clobbering a
variable's value without the need to redeclare the container.  If you
really want to program in a definitional paradigm that requires every
new definition to have a declaration, then you ought to be giving
different definitions different names, seems like, or putting each
of them into its own scope.  Or write yourself a macro.  Or just turn
off the redefinition warning...

It doesn't seem to rise to the level of a new keyword for me.

Maybe we could define an "ok" operator that suppresses only the
*first* warning produced by its argument(s).  Then if you get multiple
warnings, you at least get some indication that you've overgeneralized,
even if the "wrong" warning comes out.  Or maybe it only suppresses
the first warning till you get a second warning, and then it prints both.

In fact,

    a Str $foo = $foo;

is a nice way to indicate that from now on, you don't care about its
numeric value anymore.

All in all, I think a|an can just be my without warnings and then do
what you want.

Hm. Funny idea just occurred to me. What if something in ALLCAPS, or
better, just Ucfirst would disable all warnings for just that thing?

    my $foo;
    say $foo;  # warning about undef $foo
    Say $foo;  # no warning

    $closed_fh.print(Int($foo));  # just a warning about the closed fh

    my $foo;   # warning about new $foo masking first
    My $foo;   # no warning

If you think this looks much like PHP's @, you're right. It's not so bad
an idea, actually. The problem with PHP is that everything's a warning
and almost nothing actually dies.

No, Ucfirst it can't be, I think. And ALLCAPS is ugly. @ is taken (and
ugly). Suggestions?

    my $sql = '...' is ok;

Only trick would be getting "is ok" to bind to the thing in the
preceding expression that produces the warning the programmer was
expecting. Certainly

    {my $sql = '...'} is ok;

get the point across that warnings are somewhat ignorable for the block,
but that starts getting to look a lot like

    {my $sql = '...'} CATCH {default};

Except that one is run-time, the other compile-time.

So one could interpret this thread as a cry for a compile-time exception
handler. I see some interesting uses for this in conjunction with
C<eval>, but I doubt I'm seeing the whole story.

    {
        my $sql = q{...};
        # ... do some DB stuff ...
    }
    {
        my $sql = q{...};
        # ... do more DB stuff ...
    }

You see it in test suites all over the CPANdom.  

    ok $fh.print($foo); # no warnings about print (closed fh?)
                        # but warning about undef $foo remains

    $fh.print(ok $foo);  # warn about printing thingies, but not about
                         # undef $foo

    say $foo, $bar, ok $baz, $quux;  # complain about everything, except
                                     # what has to do with $baz

    my $foo;
    ok my $foo = "foo $bar baz";  # warn about $bar, but not the masking
    my $foo = ok "foo $bar baz";  # other way around

   temp $sql = q{...};
   my $sql = q{...};
   temp $sql = q{...};

   my $sql = q{...};
   temp $sql = q{...};
   temp $sql = q{...};

(Assuming C<temp> is made to work on lexicals, of course.)

--
Brent 'Dax' Royal-Gordon <br...@brentdax.com>
Perl and Parrot hacker

        {
                my int $i;
                loop $i=0;...;$i++ {
                        ...
                }
                do_stuff($i);
        }

But isn't:

        loop my int $i=0;...;$i++ {
                ...;
                LAST{do_stuff($i)}
        }

much cleaner? I think so, if for no other reason than it explicitly says
what it means. That's one of the reasons that LAST is so handy.

So too would my mythical declarator would prevent a few steps that are
otherwise quite easy, but cumbersome in the large.

Whatever, though. It was a simple suggestion, and seems to have sparked
FAR more controversy than the small win warrants.

      * Robs that identifier from any future possible use
      * Creates incentive to use this over "my"

You want there to be a general tendency to use "my" first. If I were to
choose a word, it would be "temp" (which I think already exists, though
I forget what it does vs "my"), or "let" (to correspond with its use in
rules).

The usual idiom for these throwaway variables is to use blocks. The
reason to want a different way to write this, I thought was wanting to
type less, especially because it's repeated throughout code.

Even if this does mean (and it does) we need something else for unit
tests.

This is the format of what I do to solve the same problem right now
in my Locale::KeyedText test suite:

     my ($sql, $foo, $bar);

     $sql = q{...};
     ...do some db stuff, also using $foo and $bar...
     $sql = q{...};
     ...do some db stuff, also using $foo and $bar...
     $sql = q{...};
     ...do some db stuff, also using $foo and $bar...

In other words, the simple solution is to declare the variable and
use it on SEPARATE LINES!  Then you can cut/copy/paste/reorder usage
lines with impunity as you wanted.

Not only does this not require a new dubious language feature, but it
also wins for brevity.

Keep it simple, as it is said.

Reserve any new syntax for when it is genuinely useful.

the $sql = q{...};
the $sth = $dbh.prepare($sql);

It could be the same as my(), but without the posessiveness (warning)