*dons the PSC hat once again...*
It is currently the case that the way Perl turns scalars into strings
will cause both the the POK ("has a string") and the IOK or NOK
("has some kind of number") flags to be set. Both flags are also set
when Perl tries to use a value that was previously a string as a
number. This means that in the following scenario, both values come out
identical:
my $was_POK = "10";
my $was_IOK = 10;
print "The values are $was_POK, $was_IOK"
if $was_POK == 10 and $was_IOK == 10;
# At this point, both scalars have both POK and IOK flags
## (Actually for the nitpickers, this may be the NOK flag, to be
## honest I'm not entirely sure but the distinction isn't important
## today)
Nicholas Clark has a PR that makes a small change to the internal Perl
function that stringifies a scalar:
https://github.com/Perl/perl5/pull/18958
The upshot of this is to change the way the flags are set on the SV
after this stringification, so that the POK flag is no longer set.
While this change is (currently) invisible from Pureperl code, it makes
an important distinction at the XS level, for example allowing things
like serialisation or encoding functions to tell the difference between
"the programmer intends this to be a string" and "the programmer
intends this to be a number".
This seems like a good idea going forward. With this change alone,
things like JSON serialisation XS modules can make use of this new
information to yield more expected results out of doing things like
this. Values that programmers expect to be numbers will still be
numbers even after you try to debug-print them and they get
stringified. They become much less fragile.
We've been slightly hesitant to merge this though, because such a
change does have the potential for some far-reaching consequences.
There is no doubt code around somewhere - on CPAN or the DarkPAN -
which may now behave differently because of it. Indeed, some may say
this is the point - we can now begin to make a distinction between
"intended as a string" and "intended as a number" where previously we
could not. It is an area which needs further exploration.
Already some modules have been tested against this branch and found to
be working fine:
https://github.com/Perl/perl5/pull/18958#issuecomment-874044458
We'd like more input though. If anyone has some code that is likely to
care about this distinction (primarily we're thinking data
serialisation and similar, but no doubt it'll pop up in other places
too) can you test it and let us know. Or, at the very least, point us
in the direction of some code that we can test for you.
It would be nice to get this in place, because it would be the first
step towards having some sort of Perl-visible distinction in these
different programmer intents. That's a longer and more interesting
discussion for another time though. For now we just want to know:
Will PR #18958 cause any breakage? Is it a good idea to merge it now?
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
It is currently the case that the way Perl turns scalars into strings
will cause both the the POK ("has a string") and the IOK or NOK
("has some kind of number") flags to be set. Both flags are also set
when Perl tries to use a value that was previously a string as a
number. This means that in the following scenario, both values come out
identical:
my $was_POK = "10";
my $was_IOK = 10;
print "The values are $was_POK, $was_IOK"
if $was_POK == 10 and $was_IOK == 10;
# At this point, both scalars have both POK and IOK flags
## (Actually for the nitpickers, this may be the NOK flag, to be
## honest I'm not entirely sure but the distinction isn't important
## today)
Nicholas Clark has a PR that makes a small change to the internal Perl
function that stringifies a scalar:
https://github.com/Perl/perl5/pull/18958
The upshot of this is to change the way the flags are set on the SV
after this stringification, so that the POK flag is no longer set.
While this change is (currently) invisible from Pureperl code, it makes
an important distinction at the XS level, for example allowing things
like serialisation or encoding functions to tell the difference between
"the programmer intends this to be a string" and "the programmer
intends this to be a number".
This seems like a good idea going forward. With this change alone,
things like JSON serialisation XS modules can make use of this new
information to yield more expected results out of doing things like
this. Values that programmers expect to be numbers will still be
numbers even after you try to debug-print them and they get
stringified. They become much less fragile.
We've been slightly hesitant to merge this though, because such a
change does have the potential for some far-reaching consequences.
There is no doubt code around somewhere - on CPAN or the DarkPAN -
which may now behave differently because of it. Indeed, some may say
this is the point - we can now begin to make a distinction between
"intended as a string" and "intended as a number" where previously we
could not. It is an area which needs further exploration.
Already some modules have been tested against this branch and found to
be working fine:
https://github.com/Perl/perl5/pull/18958#issuecomment-874044458
We'd like more input though. If anyone has some code that is likely to
care about this distinction (primarily we're thinking data
serialisation and similar, but no doubt it'll pop up in other places
too) can you test it and let us know. Or, at the very least, point us
in the direction of some code that we can test for you.
It would be nice to get this in place, because it would be the first
step towards having some sort of Perl-visible distinction in these
different programmer intents. That's a longer and more interesting
discussion for another time though. For now we just want to know:
Will PR #18958 cause any breakage? Is it a good idea to merge it now?
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/