Attempting to resolve the naming of "created_as_{string,number}"

The Pre-RFC mail raised a lot of discussion, going off into longterm
thoughts about type systems and all-else besides. I feel we're stuck
currently on the names for the currently-proposed functions, which we'd
rathermuch like to get into 5.35.10 in time for 5.36.

To help clarify the situation and focus the discussion, I'd encourage
people to actually read the RFC:

  https://github.com/Perl/RFCs/pull/13

and the implementation, which includes its documentation and tests:

  https://github.com/Perl/perl5/pull/19524

In particular (to save people reading all that text), I'll paste a key
chunk of the documentation here:

  > It is unlikely that you will want to use this for regular data
  > validation within Perl, as it will not return true for regular
  > numbers that are still perfectly usable as strings, nor for any
  > object reference - especially objects that overload the
  > stringification operator in an attempt to behave more like strings.
  >
  > For example
  >
  >     my $val = URI->new( "https://metacpan.org/" );
  >
  >     if( created_as_string $val ) { ... }    # this will not execute

The intention here is verymuch *not* attempting to create an entire
robust type system for assertions or data-validation or type-based
dynamic dispatch or any of about 20 other ideas I'm sure we could all
come up with. We can save that chat for sometime in 5.37 or 5.39 (or
7.0 devel or... whatever it'll be by then)

The focus here is a very specific narrow case. It is to help
serialiser/encoder modules (such as those which attempt to export Perl
values as JSON, MsgPack, ASN.1, or any of a variety of textual or
binary data formats) to decide what to do with a given scalar value,
once they determine it is defined, not a reference, and not a boolean.
In this specific situation, those modules want to know "does this value
prefer to be handled like a string, or like a number?"

Given all the previous discussion on this topic, about half of it can
be looked past as trying to invent more fancy type-checking functions
for other situations. This is not that situation; these are not those
functions. Lets keep focused here.

I feel that about the only point of interest anyone actually raised on
this, was the name of the functions themselves.

The RFC and code PR propose a set of names; namely

  created_as_string
  created_as_number

Given the *specific use-case* we're aiming at here (to recap: trying to
give type-intention information to data export/serialisation modules),
does anyone have any significant objections to the plan as it stands?
Either names, or behaviour.

Before commenting, please make sure to read the RFC and at least the
docs/tests part of the proposed PR.

Also, lets not forget: This whole mechanism is still tagged
"experimental" so if it turns out the name or behaviour needs changing
out into 5.36, that's still verymuch an option.

We'd just like to get something in if we can, because it complements
the PV/IV flag stablisation, and also the bool features.

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/

• Attempting to resolve the naming of "created_as_{string,number}" by Paul "LeoNerd" Evans
• Re: Attempting to resolve the naming of "created_as_{string,number}" by Paul "LeoNerd" Evans
• Re: Attempting to resolve the naming of "created_as_{string,number}" by Darren Duncan
• Re: Attempting to resolve the naming of "created_as_{string,number}" by Karl Williamson