mcs/docs/ecma334/14.6.6.xml

   1 <?xml version="1.0"?>
   2 <clause number="14.6.6" title="Cast expressions">
   3   <paragraph>A <non_terminal where="14.6.6">cast-expression</non_terminal> is used to explicitly convert an expression to a given type. <grammar_production><name><non_terminal where="14.6.6">cast-expression</non_terminal></name> : <rhs><terminal>(</terminal><non_terminal where="11">type</non_terminal><terminal>)</terminal><non_terminal where="14.6">unary-expression</non_terminal></rhs></grammar_production></paragraph>
   4   <paragraph>A <non_terminal where="14.6.6">cast-expression</non_terminal> of the form (T)E, where T is a type and E is a <non_terminal where="14.6">unary-expression</non_terminal>, performs an explicit conversion (<hyperlink>13.2</hyperlink>) of the value of E to type T. If no explicit conversion exists from the type of E to T, a compile-time error occurs. Otherwise, the result is the value produced by the explicit conversion. The result is always classified as a value, even if E denotes a variable. </paragraph>
   5   <paragraph>The grammar for a <non_terminal where="14.6.6">cast-expression</non_terminal> leads to certain syntactic ambiguities. For example, the expression  (x)-y could either be interpreted as a <non_terminal where="14.6.6">cast-expression</non_terminal> (a cast of -y to type x) or as an <non_terminal where="14.7">additive-expression</non_terminal> combined with a <non_terminal where="14.5.3">parenthesized-expression</non_terminal> (which computes the value x  -y). </paragraph>
   6   <paragraph>To resolve <non_terminal where="14.6.6">cast-expression</non_terminal> ambiguities, the following rule exists: A sequence of one or more tokens (<hyperlink>9.4</hyperlink>) enclosed in parentheses is considered the start of a <non_terminal where="14.6.6">cast-expression</non_terminal> only if at least one of the following are true: <list><list_item> The sequence of tokens is correct grammar for a type, but not for an expression. </list_item><list_item> The sequence of tokens is correct grammar for a type, and the token immediately following the closing parentheses is the token &quot;~&quot;, the token &quot;!&quot;, the token &quot;(&quot;, an identifier (<hyperlink>9.4.1</hyperlink>), a literal (<hyperlink>9.4.4</hyperlink>), or any keyword (<hyperlink>9.4.3</hyperlink>) except as and is. </list_item></list></paragraph>
   7   <paragraph>
   8     <note>[Note: The above rule means that only if the construct is unambiguously a <non_terminal where="14.6.6">cast-expression</non_terminal> is it considered a <non_terminal where="14.6.6">cast-expression</non_terminal>. end note]</note>
   9   </paragraph>
  10   <paragraph>The term &quot;correct grammar&quot; above means only that the sequence of tokens must conform to the particular grammatical production. It specifically does not consider the actual meaning of any constituent identifiers. For example, if x and y are identifiers, then x.y is correct grammar for a type, even if x.y doesn't actually denote a type. </paragraph>
  11   <paragraph>
  12     <note>[Note: From the disambiguation rule, it follows that, if x and y are identifiers, (x)y, (x)(y), and (x)(-y) are <non_terminal where="14.6.6">cast-expression</non_terminal>s, but (x)-y is not, even if x identifies a type. However, if x is a keyword that identifies a predefined type (such as <keyword>int</keyword>), then all four forms are <non_terminal where="14.6.6">cast-expression</non_terminal>s (because such a keyword could not possibly be an expression by itself). end note]</note>
  13   </paragraph>
  14 </clause>