While we've been looking at tidying up a few things around join() and
respecting concat overload, we encountered a weird case.
Code such as
join "sep", $x, $y, $z
will call OP_JOIN on the given input list and thus (at least under our
fixes) will do things like using overload magic if it exists. But when
there is a single item in the "list", code such as
join "sep", $x
will bypass it. This does not get compiled into an OP_JOIN but instead
directly becomes an OP_STRINGIFY - an opcode that exists in core perl
but doesn't have convenient syntax for it. OP_STRINGIFY directly
squashes a value down to a plain perl string, removing any
overload/magic/etc.. that might be on it. This seems perhaps surprising.
Similarly, in qq() strings, code such as:
"$x$y"
will invoke concat magic between $x and $y and return the result of
that even if it is not a plain string, but code such as:
"$x"
will directly invoke OP_STRINGIFY on the value, squashing it down to a
plain string and removing the magic.
We feel that these are weird cornercases that ideally should behave in
a more flexible, predictable and consistent manner. It suggests that it
would be nice to have a real builtin function to request that a value
get squashed down to a plain string - by invoking the '""' overload if
necessary. There's already a core OP_STRINGIFY to invoke here, so it
seems simple enough to wrap it as a new builtin - builtin::stringify.
If perl provided such a stringify function, then in the presence of the
"please make join respect overloading" flag that one-argument
specialcase can be removed, as now that special behaviour is no longer
required.
And while we're there, it would seem useful to have a similar one to
squash a value down to a plain number, by invoking the '0+' overload if
necessary. There isn't even valid perl syntax for doing this right now
- hacks such as adding zero really just invoke the '+' overload and
thus may still yield an overloaded or magic value. It'd be nice to have
a builtin::numify for this purpose.
Shall I write up a PPC document on adding these two?
* No don't do that at all
* Write a full PPC
* Just proceed directly to the PR and implement them already!
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
respecting concat overload, we encountered a weird case.
Code such as
join "sep", $x, $y, $z
will call OP_JOIN on the given input list and thus (at least under our
fixes) will do things like using overload magic if it exists. But when
there is a single item in the "list", code such as
join "sep", $x
will bypass it. This does not get compiled into an OP_JOIN but instead
directly becomes an OP_STRINGIFY - an opcode that exists in core perl
but doesn't have convenient syntax for it. OP_STRINGIFY directly
squashes a value down to a plain perl string, removing any
overload/magic/etc.. that might be on it. This seems perhaps surprising.
Similarly, in qq() strings, code such as:
"$x$y"
will invoke concat magic between $x and $y and return the result of
that even if it is not a plain string, but code such as:
"$x"
will directly invoke OP_STRINGIFY on the value, squashing it down to a
plain string and removing the magic.
We feel that these are weird cornercases that ideally should behave in
a more flexible, predictable and consistent manner. It suggests that it
would be nice to have a real builtin function to request that a value
get squashed down to a plain string - by invoking the '""' overload if
necessary. There's already a core OP_STRINGIFY to invoke here, so it
seems simple enough to wrap it as a new builtin - builtin::stringify.
If perl provided such a stringify function, then in the presence of the
"please make join respect overloading" flag that one-argument
specialcase can be removed, as now that special behaviour is no longer
required.
And while we're there, it would seem useful to have a similar one to
squash a value down to a plain number, by invoking the '0+' overload if
necessary. There isn't even valid perl syntax for doing this right now
- hacks such as adding zero really just invoke the '+' overload and
thus may still yield an overloaded or magic value. It'd be nice to have
a builtin::numify for this purpose.
Shall I write up a PPC document on adding these two?
* No don't do that at all
* Write a full PPC
* Just proceed directly to the PR and implement them already!
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/