most of the thread didn't even try to give a reason

Hm. "A string containing "OX84AB97" could be a color code; and one containing "007 James Bond" ..." responded to with "Using a rule of 'leading 0' for octal or 'leading 0x' for hex seem fairly safe -- can you give an example where doing so would be a problem?

Ignores the examples given, makes a bland naive statement, and then asks for examples. Pointless to discuss, if what is written isn't read.

I had this thought before :)

now perl gives warning

Argument "0x41" isn't numeric in printf
[download]

Very clean, things we know are numbers and can unambiguously identify as numbers, we treat as numbers, all other stuff we warn about

But if definition of numeric was expanded to include more ambiguous num formats, then perl would need a new warning

treating "0x41" as numeric , might be wrong thing to do, silence with 
+"no warnings q/extranumeric/;"
[download]

I'm confused why perl-diddler hasn't posted use extranumeric; yet :D

But if definition of numeric was expanded to include more ambiguous num formats, then perl would need a new warning: treating "0x41" as numeric , might be wrong thing to do, silence with "no warnings q/extranumeric/;"

That's a (the first) plausible approach to the proposition. It is certainly doable; but at what benefit and what cost?

Ignoring for now the old saw of backward compatibility. (Though it certainly wouldn't be ignored by the only persons whom opinions matter in this regard, namely the denizens of p5p.)

The "benefit" would be that the programmer expecting non-decimal numbers in string input could write:

print "%d\n", $string;
[download]

Rather than:

printf "%d\n", hex( $string );
[download]

And the cost would be implicitly calling hex every time a scalar currently holding a PV, is used in a numeric context.

That doesn't seem such a bad thing. (At least if it had been that way since the beginning: Ba-w-d co-pa-bil-ty!)

But, either this is going to warn "might be wrong thing" every time it finds an extranumeric and the programmers who don't want that will have to disable it; or it will be silent and the programmers that do want the warning, will have to explicitly enable it.

Seems to me that for those few that do, something like this is just as easy:

sub myHex {
    no warnings 'digit';
    hex( $_[0] };
}

printf "%d\n", myHex( $string );
[download]

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)

In the absence of evidence, opinion is indistinguishable from prejudice.

what was "rewritten to reduce confusion"?

As for 0xabcdef being a color code, that confusion already exists now, since color codes are, often, not in quotes. So the problem of "confusion" already exists.

So I already excluded octal and someone came up with color codes in hex, which are already oft unquoted, so no increase in confusion w/that example.

So back to the simple case of showing problems where allowing an auto-convert of 0x12 to 18, in a numeric context (where today, it would generate an error).

Part of the problem in finding an example where it would be a problem is you'd have to present buggy code as the example. Code that only runs with a warning and generates '0' as a binary value when used in a numeric context. That's why detractors can't find an example: it would be an example of non-working code.

Now does anyone get the point? The only way someone can accidently use "0x123456" as a binary value today...um...is they can't! They get a warning and the constant "0x123457" evaluates as binary zero. There can be no confusion in current code, because trying to decode a hex constant in a string returns a zero.

As for future code. Maybe allowing hex constants anywhere decimal constants are, as in almost any other language, won't be so confusing to "just perl programmers", since programmers in other languages don't get so easily confused -- why would anyone protest that perl programmers would?

I already ceded octal: So, now it's only hex-like strings you want to make a special case of. The ideas wearing a bit thin isn't. someone came up with color codes in hex, which are already oft unquoted,: It doesn't have to be quotes -- its in a string. It's only you wants to be able to treat that ambiguous string as a number.

You're like a dog with a bone tied to its tail, chasing around in circles refusing to let go! Fatuous.