On Thu Jul 05 20:36:01 2012, perl.p5p@rjbs.manxome.org wrote: > * Ricardo Signes <perl.p5p@rjbs.manxome.org> [2012-06-25T20:38:46] > > It seems open to change. The question is: what's the cost, and > what's the > > benefit? > > I think the feature seems low in both cost and benefit, with the key > difference > that once we allow "my();" we will be hard pressed to disallow it > later, if we > realize we should, Realize we should make lists inconsistent? See below. > as we'll be breaking something. I'm not entirely > opposed to > breaking code at the edges of sanity, but it sounds like there's very > little > practical argument to make this edge case permitted. Allowing "my()" > won't > really make it act like "normal" built-ins. It will make it a little > more like > one, but not enough to be worth even the relatively small risk of > future > headaches. I hope you are still open to remonstration. perldata says: The null list is represented by (). Interpolating it in a list has no effect. But what it says is not true of my($a,(),$b) even though my($a,($b,((((($c))))))) works. So things *are* inconsistent in that case. my() does not allow a list of variables in the usual Perl sense, but a list consisting of variables, and possibly sublists of variables, possibly with the + unary operator, but no nested empty lists. I still fail to see how that exception is a good thing. I would consider any case where the implementation of () (an actual op in its own right, as opposed to nothingness) leaks out to be a bug. () is supposed to be nothingness; the fact that it cannot be implemented that way for technical reasons only leaks out with my()/our()/local(). > As for the "this was made legal in 1999, but failed because of a > separate > issue," that may be the case, but I don't believe it was really done > deliberately. The grammar already allowed it before that, but it was made more explicit when the myterm rule had to be separated from term, for attributes to work. -- Father ChrysostomosThread Previous | Thread Next