blead forgot to update perlref

I see that perlref now lies^Wcontains a simplified version of reality:

    48  References are easy to use in Perl.  There is just one overriding
    49  principle: Perl does no implicit referencing or dereferencing.  When a
    50  scalar is holding a reference, it always behaves as a simple scalar.  It
    51  doesn't magically start being an array or hash or subroutine; you have to
    52  tell it explicitly to do so, by dereferencing it.

So much for there being "just one overriding principle", eh? :(

I feel that statement now has too many exceptions to be left as is.  We
muddied it even further for this release, but the attendant doc update
never happened.  I'm thinking of how things like keys $array_ref [sic] do
just as much of an autoderef as does bless, and perhaps even moreso:

    % blead -E '$array_ref = \@INC; say for keys $array_ref'
    0
    1
    2
    3
    4
    5
    6

Prototypes on array ops and hash ops have been darned shifty of late.
The leading number is how many prototypes they've had, the table is
what those prototypes were under that release:

             5.6        5.8       5.10     5.12      5.14
            ----------------------------------------------

  3 keys     \%         \%        \%        \[@%]     +
  3 values   \%         \%        \%        \[@%]     +
  3 each     \%         \%        \%        \[@%]     +

  2 push     \@@        \@@       \@@       \@@       +@
  3 pop      \@         ;\@       ;\@       ;\@       ;+
  3 shift    \@         ;\@       ;\@       ;\@       ;+
  2 unshift  \@@        \@@       \@@       \@@       +@
  3 splice   \@;$;$@    \@;$$@    \@;$$@    \@;$$@    +;$$@

See how much that has changed, and how fast?  It does mean that the
array set now gets runtime errors where before they got compile-time
errors.  Now that this is without its uses, of course.

    use v5.14;
    use warnings;

    sub show(+) {
        require Dumpvalue;
        state $prettily = new Dumpvalue::
                            tick        => q("),
                            compactDump => 1,
                            veryCompact => 1,
                        ;
        dumpValues $prettily @_;  # dative or ablative? :)
    }

    my($str, @words, %settings, @refs);

    $str = "this here and that or those over there and these and his own or hers nor thee";
    @words = split /\h*\b(and|nor|or)\b\h*/, $str;
    show $str;
    show @words;
    print "\n";

    $str = "fee=1 fie=2 foe=3 fum=4";
    %settings = $str =~ /\b(\w+)=(\S*)/g;
    show $str;
    show %settings;
    print "\n";

    @refs = \(@words, %settings);
    show @refs;

Whether that falls more into the set of uses than of *ab*uses
may depend on how much of a neophilistine you are, hm?

I feel that perlref's opening statement has gone from sufficiently honest
as to merit no emendation, to something else.  Here again is the first
paragraph in perlref that mentions "implicit":

    References are easy to use in Perl.  There is just one overriding
    principle: Perl does no implicit referencing or dereferencing.  When a
    scalar is holding a reference, it always behaves as a simple scalar.  It
    doesn't magically start being an array or hash or subroutine; you have to
    tell it explicitly to do so, by dereferencing it.

Here's how the 5.6 Camel hedged around the issue:

    To I<reference> a value, in the terminology of this chapter, is to
    create a hard reference to it.  (There's a special operator for this
    creative act.) The reference so created is simply a scalar, which
    behaves in all familiar contexts just like any other scalar.  To
    I<dereference> this scalar means to use the reference to get at the
    referent.  Both referencing and dereferencing occur only when you
    invoke certain explicit mechanisms; implicit referencing or
    dereferencing never occurs in Perl.  Well, almost never.  

It then elaborated:

    A function call I<can> use implicit pass-by-reference semantics--if it
    has a prototype declaring it that way.  If so, the caller of the
    function doesn't explicitly pass a reference, although you still have to
    dereference it explicitly within the function.  See the section
    "Prototypes" in A<CHP-6>.  And to be perfectly honest, there's also some
    behind-the-scenes dereferencing happening when you use certain kinds of
    filehandles, but that's for backward compatibility and is transparent to
    the casual user.  Finally, two built-in functions, C<bless> and C<lock>,
    each take a reference for their argument but implicitly dereference it
    to work their magic on what lies behind.  But those confessions aside,
    the basic principle still holds that Perl isn't interested in muddling
    your levels of indirection.

Now there are more built-in functions with implicit dereffing.  

perlref needs to be less untrue, and 5.14 release has made it so.
It seems wrong not to mention in perlref.

--tom

• blead forgot to update perlref by Tom Christiansen