Actually, to clarify, I consider the 0dNN syntax quite important too, and so the offered grant of up to $100 is to add *both* 0oNN plus 0dNN syntaxes, so then the 4 [bodx] are supported, like Perl 6 does. A rationale for having 0d also is that users can then write literals with leading zeros in all 4 radixes and there would be no confusion of the meaning versus 0NN both now and after the possible removal of 0NN meaning octal later. And meanwhile any 0NN in code can then give a warning to suggest either 0o or 0d depending what is meant. -- Darren Duncan Darren Duncan wrote: > Hello, > > P.S. Please cc any replies to me as I'm not subscribed to p5p. > > I would appreciate Perl 5.13.x+ having native support for octal numeric > literals having a 2-character prefix like already exists for binary and > hex numeric literals. It would take the form 0oNN, like the existing > 0bNN and 0xNN. Perl 6 specifies all of these, as well as 0dNN, and I > would like Perl 5 to have it too. > > While I had thought I read recently in a delta that this was already > implemented, on further look that doesn't seem to be the case, but > rather \oNN in strings was added. > > The perltodo with 5.13.6 still lists 0oNN support as an item. And I > know it doesn't work in 5.12.2. > > I am willing to sponsor this update as an informal grant to a maximum of > $100 (CAD, USD, AUD are all nearly at par these days), paid after the > fact either to whomever does it or paid to either TPF or EPO or similar > nonprofit. > > While that may not cover someone's time, I believe that this is a > strongly desired enough feature that there is impetus to do it anyway, > and I'd like to think it isn't too difficult. > > The primary deliverable is that I can take a released Perl 5.13.x and > use 0oNN in it as a numeric literal same as that one can use 0NN now, > but that presumably a use of the latter would produce a warning citing > to use the former instead. > > My preferred payment/donation method is electronic/internet, denominated > in the recipient's currency. > > Quality and thoroughness and exact semantics should be to the normal p5p > standards, including that there should be an added test for this. > > Similarly, 0NN could probably become deprecated at the same time, for > possible removal in 5.15.x or later. > > For bonus points, provide 0dNN also, for parity. > > Thank you in advance. > > -- Darren Duncan >Thread Previous