It seems sad, though, that reftype() won't be patched to XSRETURN_NO, especially as that makes more sense. Also, why can't the Perl version be patched to at least return !!0 instead of explicit undef?

XSRETURN_NO is how you do return !!0 in XS.

And the answer I think is here:

D:\dev\>perl -e"print defined !!0"
1
[download]

But Im hopeful that the p5p powers that be will be receptive of the idea of a _reftype() sub that returns PL_no instead of Pl_undef. (Which is what XSRETURN_NO and XSRETURN_UNDEF do.)

That's a good thing, at least for reftype(). I can see wanting to return undef from blessed() because you can bless into the empty string. But, the empty string is the representation for one of the 8 Perl scalar types. Or, am I just completely confused?

---

My criteria for good software:

1. Does it work?
2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

No, there is no perl intrinsic type that doesn't have a true value. And there are more than eight. We have: HASH, ARRAY, SCALAR, CODE, GLOB, IO, REF, and FORMAT, and then there is an intrinsic type that doesnt have its own designation, that being qr// objects, which report themselves as SCALAR but are actually not SCALAR refs. Oh, and i think in later perls you also have VERSION, (or something like that) but I could be mistaken.

Regarding making reftype() return PL_no is that one must assume that people are doing

if (defined(reftype($x))) { ... }
[download]

or variants thereof. At least thats what I would expect the objection would be to changing the return of reftype. Hence my idea of providing a _reftype().

---
$world=~s/war/peace/g