This is a live mirror of the Perl 5 development currently hosted at https://github.com/perl/perl5
perlop tweak
[perl5.git] / pod / perlop.pod
index a0aa3a0..c36d8ce 100644 (file)
@@ -322,7 +322,8 @@ operand is not enclosed in parentheses, it returns a string consisting
 of the left operand repeated the number of times specified by the right
 operand.  In list context, if the left operand is enclosed in
 parentheses or is a list formed by C<qw/STRING/>, it repeats the list.
-If the right operand is zero or negative, it returns an empty string
+If the right operand is zero or negative (raising a warning on
+negative), it returns an empty string
 or an empty list, depending on the context.
 X<x>
 
@@ -517,7 +518,9 @@ First available in Perl 5.10.1 (the 5.10.0 version behaved differently),
 binary C<~~> does a "smartmatch" between its arguments.  This is mostly
 used implicitly in the C<when> construct described in L<perlsyn>, although
 not all C<when> clauses call the smartmatch operator.  Unique among all of
-Perl's operators, the smartmatch operator can recurse.
+Perl's operators, the smartmatch operator can recurse.  The smartmatch
+operator is L<experimental|perlpolicy/experimental> and its behavior is
+subject to change.
 
 It is also unique in that all other Perl operators impose a context
 (usually string or numeric context) on their operands, autoconverting
@@ -804,8 +807,10 @@ C<"IO::Handle=GLOB(0x8039e0)">, then pattern matches against that.
 =head2 Bitwise And
 X<operator, bitwise, and> X<bitwise and> X<&>
 
-Binary "&" returns its operands ANDed together bit by bit.
-(See also L<Integer Arithmetic> and L<Bitwise String Operators>.)
+Binary "&" returns its operands ANDed together bit by bit.  Although no
+warning is currently raised, the result is not well defined when this operation
+is performed on operands that aren't either numbers (see
+L<Integer Arithmetic>) or bitstrings (see L<Bitwise String Operators>).
 
 Note that "&" has lower priority than relational operators, so for example
 the parentheses are essential in a test like
@@ -817,10 +822,13 @@ X<operator, bitwise, or> X<bitwise or> X<|> X<operator, bitwise, xor>
 X<bitwise xor> X<^>
 
 Binary "|" returns its operands ORed together bit by bit.
-(See also L<Integer Arithmetic> and L<Bitwise String Operators>.)
 
 Binary "^" returns its operands XORed together bit by bit.
-(See also L<Integer Arithmetic> and L<Bitwise String Operators>.)
+
+Although no warning is currently raised, the results are not well
+defined when these operations are performed on operands that aren't either
+numbers (see L<Integer Arithmetic>) or bitstrings (see L<Bitwise String
+Operators>).
 
 Note that "|" and "^" have lower priority than relational operators, so
 for example the brackets are essential in a test like
@@ -1427,10 +1435,12 @@ table:
    \c[      chr(27)
    \c]      chr(29)
    \c^      chr(30)
-   \c?      chr(127)
+   \c_      chr(31)
+   \c?      chr(127) # (on ASCII platforms)
 
 In other words, it's the character whose code point has had 64 xor'd with
-its uppercase.  C<\c?> is DELETE because C<ord("?") ^ 64> is 127, and
+its uppercase.  C<\c?> is DELETE on ASCII platforms because
+S<C<ord("?") ^ 64>> is 127, and
 C<\c@> is NULL because the ord of "@" is 64, so xor'ing 64 itself produces 0.
 
 Also, C<\c\I<X>> yields C< chr(28) . "I<X>"> for any I<X>, but cannot come at the
@@ -1439,14 +1449,15 @@ quote.
 
 On ASCII platforms, the resulting characters from the list above are the
 complete set of ASCII controls.  This isn't the case on EBCDIC platforms; see
-L<perlebcdic/OPERATOR DIFFERENCES> for the complete list of what these
-sequences mean on both ASCII and EBCDIC platforms.
+L<perlebcdic/OPERATOR DIFFERENCES> for a full discussion of the
+differences between these for ASCII versus EBCDIC platforms.
 
-Use of any other character following the "c" besides those listed above is
-discouraged, and some are deprecated with the intention of removing
-those in a later Perl version.  What happens for any of these
-other characters currently though, is that the value is derived by xor'ing
-with the seventh bit, which is 64.
+Use of any other character following the C<"c"> besides those listed above is
+discouraged, and as of Perl v5.20, the only characters actually allowed
+are the printable ASCII ones, minus the left brace C<"{">.  What happens
+for any of the allowed other characters is that the value is derived by
+xor'ing with the seventh bit, which is 64, and a warning raised if
+enabled.  Using the non-allowed characters generates a fatal error.
 
 To get platform independent controls, you can use C<\N{...}>.
 
@@ -1476,12 +1487,6 @@ the left with zeros to make three digits.  For larger ordinals, either use
 C<\o{}>, or convert to something else, such as to hex and use C<\x{}>
 instead.
 
-Having fewer than 3 digits may lead to a misleading warning message that says
-that what follows is ignored.  For example, C<"\128"> in the ASCII character set
-is equivalent to the two characters C<"\n8">, but the warning C<Illegal octal
-digit '8' ignored> will be thrown.  If C<"\n8"> is what you want, you can
-avoid this warning by padding your octal number with C<0>'s: C<"\0128">.
-
 =item [8]
 
 Several constructs above specify a character by a number.  That number
@@ -1546,7 +1551,9 @@ If Unicode (for example, C<\N{}> or code points of 0x100 or
 beyond) is being used, the case map used by C<\l>, C<\L>, C<\u>, and
 C<\U> is as defined by Unicode.  That means that case-mapping
 a single character can sometimes produce several characters.
-Under C<use locale>, C<\F> produces the same results as C<\L>.
+Under C<use locale>, C<\F> produces the same results as C<\L>
+for all locales but a UTF-8 one, where it instead uses the Unicode
+definition.
 
 All systems use the virtual C<"\n"> to represent a line terminator,
 called a "newline".  There is no such thing as an unvarying, physical
@@ -1692,7 +1699,7 @@ modifier has is not propagated, being restricted to those patterns
 explicitly using it.
 
 The last four modifiers listed above, added in Perl 5.14,
-control the character set semantics, but C</a> is the only one you are likely
+control the character set rules, but C</a> is the only one you are likely
 to want to specify explicitly; the other three are selected
 automatically by various pragmas.
 
@@ -1742,7 +1749,7 @@ test and never recompile by adding a C</o> (which stands for "once")
 after the trailing delimiter.
 Once upon a time, Perl would recompile regular expressions
 unnecessarily, and this modifier was useful to tell it not to do so, in the
-interests of speed.  But now, the only reasons to use C</o> are either:
+interests of speed.  But now, the only reasons to use C</o> are one of:
 
 =over
 
@@ -2581,7 +2588,7 @@ corresponding closing punctuation (that is C<)>, C<]>, C<}>, or C<< > >>).
 If the starting delimiter is an unpaired character like C</> or a closing
 punctuation, the ending delimiter is same as the starting delimiter.
 Therefore a C</> terminates a C<qq//> construct, while a C<]> terminates
-C<qq[]> and C<qq]]> constructs.
+both C<qq[]> and C<qq]]> constructs.
 
 When searching for single-character delimiters, escaped delimiters
 and C<\\> are skipped.  For example, while searching for terminating C</>,
@@ -2597,13 +2604,14 @@ safe location).
 
 For constructs with three-part delimiters (C<s///>, C<y///>, and
 C<tr///>), the search is repeated once more.
-If the first delimiter is not an opening punctuation, three delimiters must
-be same such as C<s!!!> and C<tr)))>, in which case the second delimiter
+If the first delimiter is not an opening punctuation, the three delimiters must
+be the same, such as C<s!!!> and C<tr)))>,
+in which case the second delimiter
 terminates the left part and starts the right part at once.
 If the left part is delimited by bracketing punctuation (that is C<()>,
 C<[]>, C<{}>, or C<< <> >>), the right part needs another pair of
 delimiters such as C<s(){}> and C<tr[]//>.  In these cases, whitespace
-and comments are allowed between both parts, though the comment must follow
+and comments are allowed between the two parts, though the comment must follow
 at least one whitespace character; otherwise a character expected as the 
 start of the comment may be regarded as the starting delimiter of the right part.