Karl Williamson <public@khwilliamson.com> wrote: :On 2/23/22 15:03, Graham Knop wrote: :> After the merge of https://github.com/Perl/perl5/pull/18958, it is :> possible to reliably distinguish between values that started as :> numbers vs values that started as strings. Essentially, if the POK :> flag is set, the value started as a string. If the POK flag is not set :> and IOK or NOK is set, it started as a number. These flags can be :> checked in XS, or via the B module, but cannot currently be checked in :> pure perl. For serializers, being able to detect the original type of :> a value is essential, so it would help to provide functions to provide :> this information. For example, providing builtin::isnumber and :> builtin::isstring, to go along with builtin::isbool. :> :> This does potentially have a huge impact on the language as a whole. :> While this is needed for serializers, providing easy access to this :> type data will pretty much inevitably result in people using the :> functions within perl for things like parameter validation. The values :> "2" and 2 are meant to be fully interchangeable inside perl, and new :> code distinguishing them will break many expectations. :> :> Even with caveats, I do think this is something that the language :> should provide. I am uncertain on the naming of the functions. :> builtin::isnumber and builtin::isstring are perhaps the most :> obvious, but they also imply that distinguishing these types is a :> normal thing to do. We may want the function names to be more :> opinionated, implying more strongly that they are meant to be used for :> things like serialization, not internal type checking. That feels like :> a losing battle though once any function of this type is available. : :What pops into my head is making them longer to type with sewn doubt: :builtin::was_originally_number :for example Heh, my first thought was to call it "was_number" instead. Just enough to imply origin rather than something intrinsic and permanent. HugoThread Previous