Indeed. The docs say, a scant six lines (exact figure will vary depending on renderer and font size, of course) above that, "The following API uses parts of Perl's internals in the current implementation. As such, they are efficient but may change."... but I wouldn't worry too much.
These are indeed not part of the public API of the module... but what does that mean, really? It means that they may change without notice. When, is the question, though. They clearly won't change without you upgrading the module, or perl itself. This means that you should have fair warning before they change.
But /will/ they change, even then? They've given you fair warning that they may change it. Will they? I doubt it. First off, Dan Kogi isn't the sort of person (I say, at a guess) to lightly break backwards compatablity -- even when he's given you far warning that he might do so. The function is documented, even if it warns you in the same breath. But more importantly, I don't forsee a reason for it to change. Perl's unicode handling model is very unlikely to change in the near future such that setting and getting the value of the utf8 flag will no longer become a meaningful thing to do. (Such a change would, in fact, be greatly desirable, but is very unlikely before, at the very least, 5.12.)
/me hopes that wasn't too rambily or heretical.In reply to Re^3: Recommended way to set the utf8 flag without altering the data
by theorbtwo
in thread Recommended way to set the utf8 flag without altering the data
by borisz
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |