Front page | perl.perl5.porters |
Postings from November 2011
On Wed, Nov 09, 2011 at 12:08:49PM -0500, David Golden wrote:
> On Wed, Nov 9, 2011 at 11:42 AM, Jesse Luehrs <doy@tozt.net> wrote:
> > I don't see how that restriction is useful at all then. { use v5.16; use
> > v5.14; ... } could trivially be rewritten as { use v5.16; { use v5.14;
> > ... } } and we're back where we started. What is restricting it to the
> > first statement of a block supposed to accomplish?
>
> First, I personally don't think it has to be the first statement.
>
> Second, I think that "use v5.16" should restrict "use v5.14" in scopes
> that it encloses (but limited to the file scope). Consider the
> difference:
>
> {
> use v5.16;
> ...
> {
> use v5.14; # should die
> ...
> }
> }
>
> versus:
>
> {
> use v5.16;
> ...
> }
> {
> use v5.14; # should live
> ...
> }
>
> I don't know if the first is possible without also breaking "use CGI".
> I assume so, since "use strict" manages to do so.
I think you might be being confused by lexical scopes versus dynamic scopes.
Pragmata such as strict act lexically, and a lexical scope inherits from its
enclosing lexical (compile time) scope, up to the whole-file scope.
(Unless I'm confused instead), standard lexical scoping performs exactly
what you want - within the lexical scope of any explicit C<use v5.16>, any
other explicit C<use v5.14> would be a compile time error. In blocks side by
side, one does not have one enclose the other.
Subsequent lower version numbers being fatal seems consistent.
Whether explicit C<use v5.16> should make a subsequent *higher* version
number fatal is the next logical question. If feature sets are purely
additive going forwards, then
{
use v5.16;
...
{
use v5.18;
...
}
}
seems sane, as :5.18 features (and enabled ancillary things) would be a
strict superset of things enabled by :5.16.
However, if future feature bundles take things out, then it doesn't seem
so sane. *And* I think the implication of Jesse's plan was that this was
not inconceivable. In that, a key part of it was to address the problem
of it being too hard to remove failed features from the core language,
which means that future Perl will sometimes be removing things.
Which argues that in the above code, that C<use v5.18> should be fatal.
As fatal as a C<use v5.14> in the same spot.
Nicholas Clark
Thread Previous
|
Thread Next