RFC 165: Allow Variables in tr/// (post hugo)

Hugo wrote:
> Definitely. Should be easy to implement. There is a potential for
> confusion, since it makes the tr/ lists look even more like
> m/ and s/ patterns, but I think it can only be less confusion than
> the current state of affairs. It is tempting to make it the default,
> and have a flag to turn it off (or just backwhack the dagnabbed
> dollar), and auto-translation of existing scripts would be pretty
> easy, except that it would presumably fail exactly where people
> are using the current workaround, by way of eval.
> 
> It would be helpful to tie down would should occur for @var and
> %var (but note that this one liner changed between 5.6.0 and 5.7.0:
>   crypt% setperl 5.6.0
>   crypt% perl -we '/.@x./'
>   In string, @x now must be written as \@x at -e line 1, near ".@x"
>   Execution of -e aborted due to compilation errors.
>   crypt% setperl 5.7.0
>   crypt% perl -we '/.@x./'
>   Possible unintended interpolation of @x in string at -e line 1.
>   Name "main::x" used only once: possible typo at -e line 1.
>   Use of uninitialized value in pattern match (m//) at -e line 1.
>   crypt% 
> ).

I propose adding the first para as a note and moving RFC to frozen soon.
Should it do anything for @foo and %bar?  I cant think of any
good reason.  

Richard

-- 

[email protected]