On Thu, 28 Nov 2019 17:04:01 +0000 Dave Mitchell <davem@iabyn.com> wrote: > =head2 :ro ... I like this and its semantics, and I like the fact it isn't called ":const", thus saving that for perhaps an even-stronger version one day that would guarantee no memory mutation (i.e. SV type upgrades), as may be useful for shared memory or other ideas. +1 > =head3 Reference Aliasing > > The first type, which I will call "reference aliasing", expects the > argument to be a I<reference> to something, and the signature > processing code first dereferences that argument (with dereference > overloading honoured) and aliases the parameter to the resulting > container - croaking if it's not a suitable reference. For example: > > sub foo(\$x, \@a, \%h, $other, $stuff) { ... } > > foo(\$X, [], \%H, 1, 2); > > Then within the body of foo(), $x is an alias for $X, @a for the > anonymous array, and %h for %H. This type of aliasing is more useful > for array and hash references, but scalars are supported for > completeness. Note that @a and %h are *not* slurpy parameters; they > consume a single argument, and more parameters can follow them. An often-overlooked thought - what about ref-aliases to code blocks? Now we have lexical subs, I wonder if we'd permit the following: sub MY_map(\&body, @args) { my @ret; push @ret, body($_) for @args; return @ret; } It seems a simple-enough addition of the idea to ref-alias a `my sub foo` here. -- Paul "LeoNerd" Evans leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/Thread Previous | Thread Next