We haven't really gotten seriously into the discussion yet of what perl 7 will include. All that's happened so far is one person made a premature announcement of what they wanted, (parts of) the community objected, and we backed up and created a governance process.

I certainly want perl 7 to be more than what has been so far ascribed to it, to make the major version number change truly worthwhile.

Given the state of Perl, I really think that launching a Perl 7 is crucial to its survival. Perl 5 has evolved a lot over its time, so it does make sense to draw a line in the sand with the new version number, but more critical is to simply signal that Perl is not dead, and to get people thinking about a “new version” since Perl 6 is now gone.

> Why not just add a "use new_defaults;" pragma or something that just turns on this handful of new options?

Umm. Yes exactly. The thing is that it will instead be spelled as:

    use v7;

There is already plenty of precedent for doing exactly that.

    use v5.10;
    ## enables the use of `say` `state` etc
    # use feature qw(say state);


    use v5.12;
    ## does the same as above but also
    ## - makes `use strict` mode the default
    ## - enables 'unicode_strings' feature
    # use strict;
    # use feature qw(… unicode_strings);


    use v5.16;
    ## all of the above, plus
    # use feature  qw(… fc current_sub unicode_eval evalbytes);


    use v5.28;
    ## all of the above, plus
    # use feature qw(… bitwise);

One question is what quantity and quality of changes are necessary for jumping from `v5.xxx.yyy` to `v7`.

There is also a question of what happens if you don't have a `use v_;` or equivalent statement.

(This is not an exhaustive list of questions.)

---

Personally I would think that `v7` should make the currently experimental signatures the default. It should also make the new Cor class experiment/prototype available with the `class` keyword. (Perhaps even a `method` keyword, but that is not strictly needed.)

Since both of those are currently being developed/designed, I think that `v7` should wait until then.

---

Other things that `v7` _might_ enable/change is things like the following. (Slightly edited from: https://stackoverflow.com/a/6163129/1337 ) I am not necessarily suggesting any of these, they are just possibilities.

    use utf8;
    use strict;
    use autodie;
    use warnings; 
    use warnings    qw< FATAL  utf8     >;
    use open        qw< :std  :utf8     >;
    use charnames   qw< :full >;

    use feature qw< say state switch unicode_strings
                    unicode_eval evalbytes current_sub fc
                    postderef_qq bitwise >;
    no  feature qw< indirect >;
    use IO::Handle;

    use File::Basename      qw< basename >;
    use Carp                qw< carp croak confess cluck >;
    use Encode              qw< encode decode >;
    use Unicode::Normalize  qw< NFD NFC >;

    END { close STDOUT }

    if (grep /\P{ASCII}/ => @ARGV) { 
       @ARGV = map { decode("UTF-8", $_) } @ARGV;
    }

    $0 = basename($0);  # shorter messages
    $| = 1;

    binmode(DATA, ":utf8");

    # give a full stack dump on any untrapped exceptions
    local $SIG{__DIE__} = sub {
        confess "Uncaught exception: @_" unless $^S;
    };

    # now promote run-time warnings into stack-dumped
    #   exceptions *unless* we're in an try block, in
    #   which case just cluck the stack dump instead
    local $SIG{__WARN__} = sub {
        if ($^S) { cluck   "Trapped warning: @_" } 
        else     { confess "Deadly warning: @_"  }
    };

It might even start using object based exceptions by default.

Again, one of the questions is what quantity and quality of changes are necessary for jumping from `v5.xxx.yyy` to `v7`.

(My only real opinion is that I think that signatures and Cor-like objects should be included. So it should wait until their designs are fully hammered out. The rest can be done in stages with `use v5.xxx.0;` until then.)