Document the "Unicode in package/sub names" problem;

a microfix in toke.c towards the final goal (the fix
removes the need to have quotes around Unicode package
names when calling a method on them)

p4raw-id: //depot/perl@17286

1 files changed, 17 insertions, 3 deletions

diff --git a/lib/utf8.pm b/lib/utf8.pm
index e0c4ac1966..5a37aecba8 100644
--- a/lib/utf8.pm
+++ b/lib/utf8.pm
@@ -57,9 +57,10 @@ Enabling the C<utf8> pragma has the following effect:
 Bytes in the source text that have their high-bit set will be treated
 as being part of a literal UTF-8 character.  This includes most
 literals such as identifier names, string constants, and constant
-regular expression patterns.  On EBCDIC platforms characters in
-the Latin 1 character set are treated as being part of a literal
-UTF-EBCDIC character.
+regular expression patterns.
+
+On EBCDIC platforms characters in the Latin 1 character set are
+treated as being part of a literal UTF-EBCDIC character.
 
 =back
 
@@ -131,6 +132,19 @@ functions utf8::valid, utf8::encode, utf8::decode, utf8::upgrade,
 and utf8::downgrade are always available, without a C<require utf8>
 statement-- this may change in future releases.
 
+=head1 BUGS
+
+One can have Unicode in identifier names, but not in package/class or
+subroutine names.  While some limited functionality towards this does
+exist as of Perl 5.8.0, that is more accidental than designed; use of
+Unicode for the said purposes is unsupported.
+
+One reason of this unfinishedness is its (currently) inherent
+unportability: since both package names and subroutine names may need
+to be mapped to file and directory names, the Unicode capability of
+the filesystem becomes important-- and there unfortunately aren't
+portable answers.
+
 =head1 SEE ALSO
 
 L<perlunicode>, L<bytes>