Changes in / [b0be06ac:59cde21]


Ignore:
Files:
3 added
4 deleted
10 edited

Legend:

Unmodified
Added
Removed

  • .gitignore

    rb0be06ac r59cde21  
    2727# generated by bison and lex from cfa.yy and lex.ll, respectively
    2828src/Parser/parser.output
    29 
    30 # generated by latex
    31 doc/refrat/refrat.aux
    32 doc/refrat/refrat.bbl
    33 doc/refrat/refrat.blg
    34 doc/refrat/refrat.brf
    35 doc/refrat/refrat.dvi
    36 doc/refrat/refrat.idx
    37 doc/refrat/refrat.ilg
    38 doc/refrat/refrat.ind
    39 doc/refrat/refrat.log
    40 doc/refrat/refrat.out
    41 doc/refrat/refrat.pdf
    42 doc/refrat/refrat.ps
    43 doc/refrat/refrat.toc

  • doc/refrat/refrat.tex

    rb0be06ac r59cde21  
    1 % requires tex packages: texlive-base texlive-latex-base tex-common texlive-humanities texlive-latex-extra texlive-fonts-recommended
    2 
    3 \documentclass[openright,twoside]{report}
    4 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    5 
    6 % Latex packages used in the document.
    7 
    8 \usepackage{fullpage,times}
    9 \usepackage{xspace}
    10 \usepackage{varioref}
    11 \usepackage{listings}
    12 \usepackage{latexsym}                                   % \Box
    13 \usepackage{mathptmx}                                   % better math font with "times"
    14 \usepackage[pagewise]{lineno}
    15 \renewcommand{\linenumberfont}{\scriptsize\sffamily}
    16 \usepackage[dvips,plainpages=false,pdfpagelabels,pdfpagemode=UseNone,colorlinks=true,pagebackref=true,linkcolor=blue,citecolor=blue,urlcolor=blue,pagebackref=true,breaklinks=true]{hyperref}
    17 \usepackage{breakurl}
    18 \urlstyle{sf}
    19 
    20 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    21 
    22 % Names used in the document.
    23 
    24 \newcommand{\CFA}{Cforall\xspace}               % set language text name
    25 \newcommand{\CFAA}{C$\forall$\xspace}   % set language symbolic name
    26 \newcommand{\CC}{C\kern-.1em\hbox{+\kern-.25em+}\xspace} % CC symbolic name
    27 \def\c11{ISO/IEC C} % C11 name (cannot have numbers in latex command name)
    28 
    29 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    30 
    31 % Specialized macros used in the document.
    32 
    33 \newcommand{\italic}[1]{\emph{\hyperpage{#1}}}
    34 \newcommand{\definition}[1]{\textbf{\hyperpage{#1}}}
    35 \newcommand{\see}[1]{\emph{see} #1}
    36 
    37 \makeatletter
    38 % Define some commands that produce formatted index entries suitable for cross-references.
    39 % ``\spec'' produces entries for specifications of entities.  ``\impl'' produces entries for their
    40 % implementations, and ``\use'' for their uses.
    41 
    42 %  \newcommand{\bold}[1]{{\bf #1}}
    43 %  \def\spec{\@bsphack\begingroup
    44 %             \def\protect##1{\string##1\space}\@sanitize
    45 %             \@wrxref{|bold}}
    46 \def\impl{\@bsphack\begingroup
    47           \def\protect##1{\string##1\space}\@sanitize
    48           \@wrxref{|definition}}
    49 \newcommand{\indexcode}[1]{{\lstinline$#1$}}
    50 \def\use{\@bsphack\begingroup
    51          \def\protect##1{\string##1\space}\@sanitize
    52          \@wrxref{|hyperpage}}
    53 \def\@wrxref#1#2{\let\thepage\relax
    54     \xdef\@gtempa{\write\@indexfile{\string
    55     \indexentry{#2@{\lstinline$#2$}#1}{\thepage}}}\endgroup\@gtempa
    56     \if@nobreak \ifvmode\nobreak\fi\fi\@esphack}
    57 \makeatother
    58 %\newcommand{\use}[1]{\index{#1@{\lstinline$#1$}}}
    59 %\newcommand{\impl}[1]{\index{\protect#1@{\lstinline$\protect#1$}|definition}}
    60 
    61 \newcommand{\define}[1]{\emph{#1\/}\index{#1}}
    62 \newenvironment{rationale}{%
    63   \begin{quotation}\noindent$\Box$\enspace
    64 }{%
    65   \hfill\enspace$\Box$\end{quotation}
    66 }%
    67 \newcommand{\rewrite}{\(\Rightarrow\)}
    68 \newcommand{\rewriterules}{\paragraph{Rewrite Rules}\hskip1em\par\noindent}
    69 \newcommand{\examples}{\paragraph{Examples}\hskip1em\par\noindent}
    70 \newcommand{\semantics}{\paragraph{Semantics}\hskip1em\par\noindent}
    71 \newcommand{\constraints}{\paragraph{Constraints}\hskip1em\par\noindent}
    72 \newenvironment{predefined}{%
    73   \paragraph{Predefined Identifiers}%
    74 %  \begin{code}%
    75 }{%
    76 %  \end{code}
    77 }%
    78 
    79 \def\syntax{\paragraph{Syntax}\trivlist\parindent=.5in\item[\hskip.5in]}
    80 \let\endsyntax=\endtrivlist
    81 \newcommand{\lhs}[1]{\par{\emph{#1:}}\index{#1@{\emph{#1}}|italic}}
    82 \newcommand{\rhs}{\hfil\break\hbox{\hskip1in}}
    83 \newcommand{\oldlhs}[1]{\emph{#1: \ldots}\index{#1@{\emph{#1}}|italic}}
    84 \newcommand{\nonterm}[1]{\emph{#1\/}\index{#1@{\emph{#1}}|italic}}
    85 \newcommand{\opt}{$_{opt}$\ }
    86 
    87 \renewcommand{\reftextfaceafter}{\unskip}
    88 \renewcommand{\reftextfacebefore}{\unskip}
    89 \renewcommand{\reftextafter}{\unskip}
    90 \renewcommand{\reftextbefore}{\unskip}
    91 \renewcommand{\reftextfaraway}[1]{\unskip, p.~\pageref{#1}}
    92 \renewcommand{\reftextpagerange}[2]{\unskip, pp.~\pageref{#1}--\pageref{#2}}
    93 \newcommand{\VRef}[2][Section]{\ifx#1\@empty\else{#1}\nobreakspace\fi\vref{#2}}
    94 \newcommand{\VPageref}[2][page]{\ifx#1\@empty\else{#1}\nobreakspace\fi\pageref{#2}}
    95 
    96 % replace/adjust characters that look bad in sanserif
    97 \makeatletter
    98 \lst@CCPutMacro
    99 \lst@ProcessOther{"2D}{\lst@ttfamily{-{}}{{\ttfamily\upshape -}}} % replace minus
    100 \lst@ProcessOther{"3C}{\lst@ttfamily{<}{\texttt{<}}} % replace less than
    101 \lst@ProcessOther{"3E}{\lst@ttfamily{<}{\texttt{>}}} % replace greater than
    102 \lst@ProcessOther{"5E}{\raisebox{0.4ex}{$\scriptstyle\land\,$}} % circumflex
    103 \lst@ProcessLetter{"5F}{\lst@ttfamily{\char95}{{\makebox[1.2ex][c]{\rule{1ex}{0.1ex}}}}} % replace underscore
    104 %\lst@ProcessOther{"7E}{\raisebox{-.4ex}[1ex][0pt]{\textasciitilde}} % lower tilde
    105 \lst@ProcessOther{"7E}{\raisebox{0.3ex}{$\scriptstyle\sim\,$}} % lower tilde
    106 \@empty\z@\@empty
    107 
    108 \newcommand{\Index}{\@ifstar\@sIndex\@Index}
    109 \newcommand{\@Index}[2][\@empty]{\lowercase{\def\temp{#2}}#2\ifx#1\@empty\index{\temp}\else\index{#1@{\protect#2}}\fi}
    110 \newcommand{\@sIndex}[2][\@empty]{#2\ifx#1\@empty\index{#2}\else\index{#1@{\protect#2}}\fi}
    111 \makeatother
    112 
    113 \lstdefinelanguage{CFA}[ANSI]{C}%
    114   {morekeywords={asm,_Atomic,catch,catchResume,choose,_Complex,context,disable,dtype,enable,
    115         fallthru,finally,forall,ftype,_Imaginary,lvalue,restrict,throw,throwResume,try,type,},
    116 }
    117 
    118 \lstset{
    119 language=CFA,
    120 columns=fullflexible,
    121 basicstyle=\sf\small,
    122 tabsize=4,
    123 xleftmargin=\parindent,
    124 escapechar=@,
    125 %fancyvrb=true,
    126 %showtabs=true,
    127 keepspaces=true,
    128 showtabs=true,
    129 tab=,
    130 }
    131 
    132 \setcounter{secnumdepth}{3}     % number subsubsections
    133 \setcounter{tocdepth}{3}                % subsubsections in table of contents
    134 \makeindex
    135 
    136 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    137 
    138 \begin{document}
    139 \pagestyle{headings}
    140 \linenumbers                                    % comment out to turn off line numbering
    141 
    142 \title{\CFA (\CFAA) Reference Manual and Rationale}
    143 \author{Glen Ditchfield}
    144 \date{DRAFT\\\today}
    145 
    146 \pagenumbering{roman}
    147 \pagestyle{plain}
    148 
    149 \maketitle
    150 
    151 \vspace*{\fill}
    152 \thispagestyle{empty}
    153 \noindent
    154 \copyright\,2015 Glen Ditchfield \\ \\
    155 \noindent
    156 This work is licensed under the Creative Commons Attribution 4.0 International License. To view a
    157 copy of this license, visit {\small\url{http://creativecommons.org/licenses/by/4.0}}.
    158 \vspace*{1in}
    159 
    160 \clearpage
    161 \pdfbookmark[1]{Contents}{section}
    162 \tableofcontents
    163 
    164 \clearpage
    165 \pagenumbering{arabic}
    166 
    167 
    168 \chapter*{Introduction}\addcontentsline{toc}{chapter}{Introduction}
    169 
    170 This document is a reference manual and rationale for \CFA, a polymorphic extension of the C
    171 programming language. It makes frequent reference to the {\c11} standard \cite{ANS:C11}, and
    172 occasionally compares \CFA to {\CC} \cite{c++}.
    173 
    174 The manual deliberately imitates the ordering of the {\c11} standard (although the section numbering
    175 differs). Unfortunately, this means that the manual contains more ``forward references'' than
    176 usual, and that it will be hard to follow if the reader does not have a copy of the {\c11} standard
    177 near-by. For a gentle introduction to \CFA, see the companion document ``An Overview of
    178 \CFA'' \cite{Ditchfield96:Overview}.
    179 
    180 \begin{rationale}
    181 Commentary (like this) is quoted with quads. Commentary usually deals with subtle points, the
    182 rationale behind a rule, and design decisions.
    183 \end{rationale}
    184 
    185 % No ``Scope'' or ``Normative references'' chapters yet.
    186 \setcounter{chapter}{2}
    187 \chapter{Terms, definitions, and symbols}
    188 Terms from the {\c11} standard used in this document have the same meaning as in the {\c11}
    189 standard.
    190 
    191 % No ``Conformance'' or ``Environment'' chapters yet.
    192 \setcounter{chapter}{5}
    193 \chapter{Language}
    194 \section{Notation}
    195 The syntax notation used in this document is the same as is used in the {\c11} standard, with one
    196 exception: ellipsis in the definition of a nonterminal, as in ``\emph{declaration:} \ldots'',
    197 indicates that these rules extend a previous definition, which occurs in this document or in the
    198 {\c11} standard.
    199 
    200 
    201 \section{Concepts}
    202 
    203 
    204 \subsection{Scopes of identifiers}\index{scopes}
    205 
    206 \CFA's scope rules differ from C's in one major respect: a declaration of an identifier may
    207 overload\index{overloading} outer declarations of lexically identical identifiers in the same
    208 \Index{name space}, instead of hiding them. The outer declaration is hidden if the two declarations
    209 have \Index{compatible type}, or if one declares an array type and the other declares a pointer type
    210 and the element type and pointed-at type are compatible, or if one has function type and the other
    211 is a pointer to a compatible function type, or if one declaration is a \lstinline$type$\use{type} or
    212 \lstinline$typedef$\use{typedef} declaration and the other is not.  The outer declaration becomes
    213 \Index{visible} when the scope of the inner declaration terminates.
    214 \begin{rationale}
    215 Hence, a \CFA program can declare an \lstinline$int v$ and a \lstinline$float v$ in the same
    216 scope; a {\CC} program can not.
    217 \end{rationale}
    218 
    219 
    220 \subsection{Linkage of identifiers}
    221 \index{linkage}
    222 
    223 \CFA's linkage rules differ from C's in only one respect: instances of a particular identifier with
    224 external or internal linkage do not necessarily denote the same object or function. Instead, in the
    225 set of translation units and libraries that constitutes an entire program, any two instances of a
    226 particular identifier with \Index{external linkage} denote the same object or function if they have
    227 \Index{compatible type}s, or if one declares an array type and the other declares a pointer type and
    228 the element type and pointed-at type are compatible, or if one has function type and the other is a
    229 pointer to a compatible function type. Within one translation unit, each instance of an identifier
    230 with \Index{internal linkage} denotes the same object or function in the same circumstances.
    231 Identifiers with \Index{no linkage} always denote unique entities.
    232 \begin{rationale}
    233 A \CFA program can declare an \lstinline$extern int v$ and an \lstinline$extern float v$; a C
    234 program cannot.
    235 \end{rationale}
    236 
    237 \section{Conversions}
    238 \CFA defines situations where values of one type are automatically converted to another type.
    239 These conversions are called \define{implicit conversion}s. The programmer can request
    240 \define{explicit conversion}s using cast expressions.
    241 
    242 
    243 \subsection{Arithmetic operands}
    244 \setcounter{subsubsection}{7}
    245 
    246 
    247 \subsubsection{Safe arithmetic conversions}
    248 In C, a pattern of conversions known as the \define{usual arithmetic conversion}s is used with most
    249 binary arithmetic operators to convert the operands to a common type and determine the type of the
    250 operator's result. In \CFA, these conversions play a role in overload resolution, and
    251 collectively are called the \define{safe arithmetic conversion}s.
    252 
    253 Let \(int_r\) and \(unsigned_r\) be the signed and unsigned integer types with integer conversion
    254 rank\index{integer conversion rank}\index{rank|see{integer conversion rank}} $r$. Let
    255 \(unsigned_{mr}\) be the unsigned integer type with maximal rank.
    256 
    257 The following conversions are \emph{direct} safe arithmetic conversions.
    258 \begin{itemize}
    259 \item
    260 The \Index{integer promotion}s.
    261 
    262 \item
    263 For every rank $r$ greater than or equal to the rank of \lstinline$int$, conversion from \(int_r\)
    264 to \(unsigned_r\).
    265 
    266 \item
    267 For every rank $r$ greater than or equal to the rank of \lstinline$int$, where \(int_{r+1}\) exists
    268 and can represent all values of \(unsigned_r\), conversion from \(unsigned_r\) to \(int_{r+1}\).
    269 
    270 \item
    271 Conversion from \(unsigned_{mr}\) to \lstinline$float$.
    272 
    273 \item
    274 Conversion from an enumerated type to its compatible integer type.
    275 
    276 \item
    277 Conversion from \lstinline$float$ to \lstinline$double$, and from \lstinline$double$ to
    278 \lstinline$long double$.
    279 
    280 \item
    281 Conversion from \lstinline$float _Complex$ to \lstinline$double _Complex$,
    282 and from \lstinline$double _Complex$ to \lstinline$long double _Complex$.
    283 
    284 \begin{sloppypar}
    285 \item
    286 Conversion from \lstinline$float _Imaginary$ to \lstinline$double _Imaginary$, and from
    287 \lstinline$double _Imaginary$ to \lstinline$long double$ \lstinline$_Imaginary$, if the
    288 implementation supports imaginary types.
    289 \end{sloppypar}
    290 \end{itemize}
    291 
    292 If type \lstinline$T$ can be converted to type \lstinline$U$ by a safe direct arithmetic conversion
    293 and type \lstinline$U$ can be converted to type \lstinline$V$ by a safe arithmetic conversion, then
    294 the conversion from \lstinline$T$ to type \lstinline$V$ is an \emph{indirect} safe arithmetic
    295 conversion.
    296 
    297 \begin{rationale}
    298 Note that {\c11} does not include conversion from \Index{real type}s to \Index{complex type}s in the
    299 usual arithmetic conversions, and \CFA does not include them as safe conversions.
    300 \end{rationale}
    301 
    302 
    303 \subsection{Other operands}
    304 \setcounter{subsubsection}{3}
    305 
    306 
    307 \subsubsection{Anonymous structures and unions}
    308 \label{anon-conv}
    309 
    310 If an expression's type is a pointer to a structure or union type that has a member that is an
    311 \Index{anonymous structure} or an \Index{anonymous union}, it can be implicitly
    312 converted\index{implicit conversion} to a pointer to the anonymous structure's or anonymous union's
    313 type. The result of the conversion is a pointer to the member.
    314 
    315 \examples
    316 \begin{lstlisting}
    317 struct point {
    318         int x, y;
    319 };
    320 void move_by(struct point * p1, struct point * p2) {@\impl{move_by}@
    321         p1->x += p2.x;
    322         p1->y += p2.y;
    323 }
    324 
    325 struct color_point {
    326         enum { RED, BLUE, GREEN } color;
    327         struct point;
    328 } cp1, cp2;
    329 move_to(&cp1, &cp2);
    330 \end{lstlisting}
    331 Thanks to implicit conversion, the two arguments that \lstinline$move_by()$ receives are pointers to
    332 \lstinline$cp1$'s second member and \lstinline$cp2$'s second member.
    333 
    334 
    335 \subsubsection{Specialization}
    336 A function or value whose type is polymorphic may be implicitly converted to one whose type is
    337 \Index{less polymorphic} by binding values to one or more of its \Index{inferred parameter}. Any
    338 value that is legal for the inferred parameter may be used, including other inferred parameters.
    339 
    340 If, after the inferred parameter binding, an \Index{assertion parameter} has no inferred parameters
    341 in its type, then an object or function must be visible at the point of the specialization that has
    342 the same identifier as the assertion parameter and has a type that is compatible\index{compatible
    343   type} with or can be specialized to the type of the assertion parameter.  The assertion parameter
    344 is bound to that object or function.
    345 
    346 The type of the specialization is the type of the original with the bound inferred parameters and
    347 the bound assertion parameters replaced by their bound values.
    348 
    349 \examples
    350 The type
    351 \begin{lstlisting}
    352 forall( type T, type U ) void (*)( T, U );
    353 \end{lstlisting}
    354 can be specialized to (among other things)
    355 \begin{lstlisting}
    356 forall( type T ) void (*)( T, T );              // U bound to T
    357 forall( type T ) void (*)( T, real );   // U bound to real
    358 forall( type U ) void (*)( real, U );   // T bound to real
    359 void f( real, real );                                   // both bound to real
    360 \end{lstlisting}
    361 
    362 The type
    363 \begin{lstlisting}
    364 forall( type T | T ?+?( T, T )) T (*)( T );
    365 \end{lstlisting}
    366 can be specialized to (among other things)
    367 \begin{lstlisting}
    368 int (*)( int );                                         // T bound to int, and T ?+?(T, T ) bound to int ?+?( int, int )
    369 \end{lstlisting}
    370 
    371 
    372 \subsubsection{Safe conversions}
    373 
    374 A \define{direct safe conversion} is one of the following conversions:
    375 \begin{itemize}
    376 \item
    377 a direct safe arithmetic conversion;
    378 \item
    379 from any object type or incomplete type to \lstinline$void$;
    380 \item
    381 from a pointer to any non-\lstinline$void$ type to a pointer to \lstinline$void$;
    382 \item
    383 from a pointer to any type to a pointer to a more qualified version of the type\index{qualified
    384 type};
    385 \item
    386 from a pointer to a structure or union type to a pointer to the type of a member of the structure or
    387 union that is an \Index{anonymous structure} or an \Index{anonymous union};
    388 \item
    389 within the scope of an initialized \Index{type declaration}, conversions between a type and its
    390 implementation or between a pointer to a type and a pointer to its implementation.
    391 \end{itemize}
    392 
    393 Conversions that are not safe conversions are \define{unsafe conversion}s.
    394 \begin{rationale}
    395 As in C, there is an implicit conversion from \lstinline$void *$ to any pointer type. This is
    396 clearly dangerous, and {\CC} does not have this implicit conversion.
    397 \CFA\index{deficiencies!void * conversion} keeps it, in the interest of remaining as pure a
    398 superset of C as possible, but discourages it by making it unsafe.
    399 \end{rationale}
    400 
    401 
    402 \subsection{Conversion cost}
    403 
    404 The \define{conversion cost} of a safe\index{safe conversion}
    405 conversion\footnote{Unsafe\index{unsafe conversion} conversions do not have defined conversion
    406 costs.} is a measure of how desirable or undesirable it is. It is defined as follows.
    407 \begin{itemize}
    408 \item
    409 The cost of a conversion from any type to itself is 0.
    410 
    411 \item
    412 The cost of a direct safe conversion is 1.
    413 
    414 \item
    415 The cost of an indirect safe arithmetic conversion is the smallest number of direct conversions
    416 needed to make up the conversion.
    417 \end{itemize}
    418 
    419 \examples
    420 In the following, assume an implementation that does not provide any extended integer types.
    421 
    422 \begin{itemize}
    423 \item
    424 The cost of an implicit conversion from \lstinline$int$ to \lstinline$long$ is 1. The cost of an
    425 implicit conversion from \lstinline$long$ to \lstinline$double$ is 3, because it is defined in terms
    426 of conversions from \lstinline$long$ to \lstinline$unsigned long$, then to \lstinline$float$, and
    427 then to \lstinline$double$.
    428 
    429 \item
    430 If \lstinline$int$ can represent all the values of \lstinline$unsigned short$, then the cost of an
    431 implicit conversion from \lstinline$unsigned short$ to \lstinline$unsigned$ is 2:
    432 \lstinline$unsigned short$ to \lstinline$int$ to \lstinline$unsigned$. Otherwise,
    433 \lstinline$unsigned short$ is converted directly to \lstinline$unsigned$, and the cost is 1.
    434 
    435 \item
    436 If \lstinline$long$ can represent all the values of \lstinline$unsigned$, then the conversion cost
    437 of \lstinline$unsigned$ to \lstinline$long$ is 1. Otherwise, the conversion is an unsafe
    438 conversion, and its conversion cost is undefined.
    439 \end{itemize}
    440 
    441 \section{Lexical elements}
    442 \subsection{Keywords}
    443 \begin{syntax}
    444 \oldlhs{keyword}
    445         \rhs \lstinline$forall$
    446         \rhs \lstinline$lvalue$
    447         \rhs \lstinline$context$
    448         \rhs \lstinline$dtype$
    449         \rhs \lstinline$ftype$
    450         \rhs \lstinline$type$
    451 \end{syntax}
    452 
    453 
    454 \subsection{Identifiers}
    455 
    456 \CFA allows operator \Index{overloading} by associating operators with special function
    457 identifiers. Furthermore, the constants ``\lstinline$0$'' and ``\lstinline$1$'' have special status
    458 for many of C's data types (and for many programmer-defined data types as well), so \CFA treats them
    459 as overloadable identifiers. Programmers can use these identifiers to declare functions and objects
    460 that implement operators and constants for their own types.
    461 
    462 
    463 \setcounter{subsubsection}{2}
    464 \subsubsection{Constant identifiers}
    465 
    466 \begin{syntax}
    467 \oldlhs{identifier}
    468 \rhs \lstinline$0$
    469 \rhs \lstinline$1$
    470 \end{syntax}
    471 
    472 \index{constant identifiers}\index{identifiers!for constants} The tokens ``\lstinline$0$''\impl{0}
    473 and ``\lstinline$1$''\impl{1} are identifiers. No other tokens defined by the rules for integer
    474 constants are considered to be identifiers.
    475 \begin{rationale}
    476 Why ``\lstinline$0$'' and ``\lstinline$1$''? Those integers have special status in C. All scalar
    477 types can be incremented and decremented, which is defined in terms of adding or subtracting 1. The
    478 operations ``\lstinline$&&$'', ``\lstinline$||$'', and ``\lstinline$!$'' can be applied to any
    479 scalar arguments, and are defined in terms of comparison against 0. A \nonterm{constant-expression}
    480 that evaluates to 0 is effectively compatible with every pointer type.
    481 
    482 In C, the integer constants 0 and 1 suffice because the integer promotion rules can convert them to
    483 any arithmetic type, and the rules for pointer expressions treat constant expressions evaluating to
    484 0 as a special case. However, user-defined arithmetic types often need the equivalent of a 1 or 0
    485 for their functions or operators, polymorphic functions often need 0 and 1 constants of a type
    486 matching their polymorphic parameters, and user-defined pointer-like types may need a null value.
    487 Defining special constants for a user-defined type is more efficient than defining a conversion to
    488 the type from \lstinline$_Bool$.
    489 
    490 Why \emph{just} ``\lstinline$0$'' and ``\lstinline$1$''? Why not other integers? No other integers
    491 have special status in C. A facility that let programmers declare specific
    492 constants---``\lstinline$const Rational 12$'', for instance---would not be much of an improvement.
    493 Some facility for defining the creation of values of programmer-defined types from arbitrary integer
    494 tokens would be needed. The complexity of such a feature doesn't seem worth the gain.
    495 \end{rationale}
    496 
    497 
    498 \subsubsection{Operator identifiers}
    499 
    500 \index{operator identifiers}\index{identifiers!for operators} Table \ref{opids} lists the
    501 programmer-definable operator identifiers and the operations they are associated with. Functions
    502 that are declared with (or pointed at by function pointers that are declared with) these identifiers
    503 can be called by expressions that use the operator tokens and syntax, or the operator identifiers
    504 and ``function call'' syntax. The relationships between operators and function calls are discussed
    505 in descriptions of the operators.
    506 
    507 \begin{table}[hbt]
    508 \hfil
    509 \begin{tabular}[t]{ll}
    510 %identifier & operation \\ \hline
    511 \lstinline$?[?]$ & subscripting \impl{?[?]}\\
    512 \lstinline$?()$ & function call \impl{?()}\\
    513 \lstinline$?++$ & postfix increment \impl{?++}\\
    514 \lstinline$?--$ & postfix decrement \impl{?--}\\
    515 \lstinline$++?$ & prefix increment \impl{++?}\\
    516 \lstinline$--?$ & prefix decrement \impl{--?}\\
    517 \lstinline$*?$ & dereference \impl{*?}\\
    518 \lstinline$+?$ & unary plus \impl{+?}\\
    519 \lstinline$-?$ & arithmetic negation \impl{-?}\\
    520 \lstinline$~?$ & bitwise negation \impl{~?}\\
    521 \lstinline$!?$ & logical complement \impl{"!?}\\
    522 \lstinline$?*?$ & multiplication \impl{?*?}\\
    523 \lstinline$?/?$ & division \impl{?/?}\\
    524 \end{tabular}\hfil
    525 \begin{tabular}[t]{ll}
    526 %identifier & operation \\ \hline
    527 \lstinline$?%?$ & remainder \impl{?%?}\\
    528 \lstinline$?+?$ & addition \impl{?+?}\\
    529 \lstinline$?-?$ & subtraction \impl{?-?}\\
    530 \lstinline$?<<?$ & left shift \impl{?<<?}\\
    531 \lstinline$?>>?$ & right shift \impl{?>>?}\\
    532 \lstinline$?<?$ & less than \impl{?<?}\\
    533 \lstinline$?<=?$ & less than or equal \impl{?<=?}\\
    534 \lstinline$?>=?$ & greater than or equal \impl{?>=?}\\
    535 \lstinline$?>?$ & greater than \impl{?>?}\\
    536 \lstinline$?==?$ & equality \impl{?==?}\\
    537 \lstinline$?!=?$ & inequality \impl{?"!=?}\\
    538 \lstinline$?&?$ & bitwise AND \impl{?&?}\\
    539 \end{tabular}\hfil
    540 \begin{tabular}[t]{ll}
    541 %identifier & operation \\ \hline
    542 \lstinline$?^?$ & exclusive OR \impl{?^?}\\
    543 \lstinline$?|?$ & inclusive OR \impl{?"|?}\\
    544 \lstinline$?=?$ & simple assignment \impl{?=?}\\
    545 \lstinline$?*=?$ & multiplication assignment \impl{?*=?}\\
    546 \lstinline$?/=?$ & division assignment \impl{?/=?}\\
    547 \lstinline$?%=?$ & remainder assignment \impl{?%=?}\\
    548 \lstinline$?+=?$ & addition assignment \impl{?+=?}\\
    549 \lstinline$?-=?$ & subtraction assignment \impl{?-=?}\\
    550 \lstinline$?<<=?$ & left-shift assignment \impl{?<<=?}\\
    551 \lstinline$?>>=?$ & right-shift assignment \impl{?>>=?}\\
    552 \lstinline$?&=?$ & bitwise AND assignment \impl{?&=?}\\
    553 \lstinline$?^=?$ & exclusive OR assignment \impl{?^=?}\\
    554 \lstinline$?|=?$ & inclusive OR assignment \impl{?"|=?}\\
    555 \end{tabular}
    556 \hfil
    557 \caption{Operator Identifiers}
    558 \label{opids}
    559 \end{table}
    560 
    561 \begin{rationale}
    562 Operator identifiers are made up of the characters of the operator token, with question marks added
    563 to mark the positions of the arguments of operators. The question marks serve as mnemonic devices;
    564 programmers can not create new operators by arbitrarily mixing question marks and other
    565 non-alphabetic characters. Note that prefix and postfix versions of the increment and decrement
    566 operators are distinguished by the position of the question mark.
    567 \end{rationale}
    568 
    569 \begin{rationale}
    570 The use of ``\lstinline$?$'' in identifiers means that some C programs are not \CFA programs.
    571 For instance, the sequence of characters ``\lstinline$(i < 0)?--i:i$'' is legal in a C program, but
    572 a \CFA compiler will detect a syntax error because it will treat ``\lstinline$?--$'' as an
    573 identifier, not as the two tokens ``\lstinline$?$'' and ``\lstinline$--$''.
    574 \end{rationale}
    575 
    576 \begin{rationale}
    577 Certain operators \emph{cannot} be defined by the programmer:
    578 \begin{itemize}
    579 \item
    580 The logical operators ``\lstinline$&&$'' and ``\lstinline$||$'', and the conditional operator
    581 ``\lstinline$?:$''. These operators do not always evaluate their operands, and hence can not be
    582 properly defined by functions unless some mechanism like call-by-name is added to the language.
    583 Note that the definitions of ``\lstinline$&&$'' and ``\lstinline$||$'' say that they work by
    584 checking that their arguments are unequal to 0, so defining ``\lstinline$!=$'' and ``\lstinline$0$''
    585 for user-defined types is enough to allow them to be used in logical expressions.
    586 
    587 \item
    588 The comma operator\index{comma expression}. It is a control-flow operator like those above.
    589 Changing its meaning seems pointless and confusing.
    590 
    591 \item
    592 The ``address of'' operator. It would seem useful to define a unary ``\lstinline$&$'' operator that
    593 returns values of some programmer-defined pointer-like type. The problem lies with the type of the
    594 operator. Consider the expression ``\lstinline$p = &x$'', where \lstinline$x$ is of type
    595 \lstinline$T$ and \lstinline$p$ has the programmer-defined type \lstinline$T_ptr$. The expression
    596 might be treated as a call to the unary function ``\lstinline$&?$''. Now what is the type of the
    597 function's parameter? It can not be \lstinline$T$, because then \lstinline$x$ would be passed by
    598 value, and there is no way to create a useful pointer-like result from a value. Hence the parameter
    599 must have type \lstinline$T *$. But then the expression must be rewritten as ``\lstinline$p = &?( &x )$''
    600 ---which doesn't seem like progress!
    601 
    602 The rule for address-of expressions would have to be something like ``keep applying address-of
    603 functions until you get one that takes a pointer argument, then use the built-in operator and
    604 stop''. It seems simpler to define a conversion function from \lstinline$T *$ to \lstinline$T_ptr$.
    605 
    606 \item
    607 The \lstinline$sizeof$ operator. It is already defined for every object type, and intimately tied
    608 into the language's storage allocation model. Redefining it seems pointless.
    609 
    610 \item
    611 The ``member of'' operators ``\lstinline$.$'' and ``\lstinline$->$''. These are not really infix
    612 operators, since their right ``operand'' is not a value or object.
    613 
    614 \item
    615 Cast operators\index{cast expression}. Anything that can be done with an explicit cast can be done
    616 with a function call. The difference in syntax is small.
    617 \end{itemize}
    618 \end{rationale}
    619 
    620 
    621 \section{Expressions}
    622 
    623 \CFA allows operators and identifiers to be overloaded. Hence, each expression can have a number
    624 of \define{interpretation}s, each of which has a different type. The interpretations that are
    625 potentially executable are called \define{valid interpretation}s. The set of interpretations
    626 depends on the kind of expression and on the interpretations of the subexpressions that it contains.
    627 The rules for determining the valid interpretations of an expression are discussed below for each
    628 kind of expression. Eventually the context of the outermost expression chooses one interpretation
    629 of that expression.
    630 
    631 An \define{ambiguous interpretation} is an interpretation which does not specify the exact object or
    632 function denoted by every identifier in the expression. An expression can have some interpretations
    633 that are ambiguous and others that are unambiguous. An expression that is chosen to be executed
    634 shall not be ambiguous.
    635 
    636 The \define{best valid interpretations} are the valid interpretations that use the fewest
    637 unsafe\index{unsafe conversion} conversions. Of these, the best are those where the functions and
    638 objects involved are the least polymorphic\index{less polymorphic}. Of these, the best have the
    639 lowest total \Index{conversion cost}, including all implicit conversions in the argument
    640 expressions. Of these, the best have the highest total conversion cost for the implicit conversions
    641 (if any) applied to the argument expressions. If there is no single best valid interpretation, or if
    642 the best valid interpretation is ambiguous, then the resulting interpretation is
    643 ambiguous\index{ambiguous interpretation}.
    644 
    645 \begin{rationale}
    646 \CFA's rules for selecting the best interpretation are designed to allow overload resolution to
    647 mimic C's operator semantics. In C, the ``usual arithmetic conversions'' are applied to the
    648 operands of binary operators if necessary to convert the operands to types with a common real type.
    649 In \CFA, those conversions are ``safe''. The ``fewest unsafe conversions'' rule ensures that the
    650 usual conversions are done, if possible. The ``lowest total expression cost'' rule chooses the
    651 proper common type. The odd-looking ``highest argument conversion cost'' rule ensures that, when
    652 unary expressions must be converted, conversions of function results are preferred to conversion of
    653 function arguments: \lstinline$(double)-i$ will be preferred to \lstinline$-(double)i$.
    654 
    655 The ``least polymorphic'' rule reduces the number of polymorphic function calls, since such
    656 functions are presumably more expensive than monomorphic functions and since the more specific
    657 function is presumably more appropriate. It also gives preference to monomorphic values (such as the
    658 \lstinline$int$ \lstinline$0$) over polymorphic values (such as the \Index{null pointer}
    659 \lstinline$0$\use{0}). However, interpretations that call polymorphic functions are preferred to
    660 interpretations that perform unsafe conversions, because those conversions potentially lose accuracy
    661 or violate strong typing.
    662 
    663 There are two notable differences between \CFA's overload resolution rules and the rules for
    664 {\CC} defined in \cite{c++}. First, the result type of a function plays a role. In {\CC}, a
    665 function call must be completely resolved based on the arguments to the call in most circumstances.
    666 In \CFA, a function call may have several interpretations, each with a different result type, and
    667 the interpretations of the containing context choose among them. Second, safe conversions are used
    668 to choose among interpretations of all sorts of functions; in {\CC}, the ``usual arithmetic
    669 conversions'' are a separate set of rules that apply only to the built-in operators.
    670 \end{rationale}
    671 
    672 Expressions involving certain operators\index{operator identifiers} are considered to be equivalent
    673 to function calls. A transformation from ``operator'' syntax to ``function call'' syntax is defined
    674 by \define{rewrite rules}. Each operator has a set of predefined functions that overload its
    675 identifier. Overload resolution determines which member of the set is executed in a given
    676 expression. The functions have \Index{internal linkage} and are implicitly declared with \Index{file
    677 scope}. The predefined functions and rewrite rules are discussed below for each of these
    678 operators.
    679 \begin{rationale}
    680 Predefined functions and constants have internal linkage because that simplifies optimization in
    681 traditional compile-and-link environments. For instance, ``\lstinline$an_int + an_int$'' is
    682 equivalent to ``\lstinline$?+?(an_int, an_int)$''. If integer addition has not been redefined in
    683 the current scope, a compiler can generate code to perform the addition directly. If predefined
    684 functions had external linkage, this optimization would be difficult.
    685 \end{rationale}
    686 
    687 \begin{rationale}
    688 Since each subsection describes the interpretations of an expression in terms of the interpretations
    689 of its subexpressions, this chapter can be taken as describing an overload resolution algorithm that
    690 uses one bottom-up pass over an expression tree. Such an algorithm was first described (for Ada) by
    691 Baker~\cite{Bak:overload}. It is extended here to handle polymorphic functions and arithmetic
    692 conversions. The overload resolution rules and the predefined functions have been chosen so that, in
    693 programs that do not introduce overloaded declarations, expressions will have the same meaning in C
    694 and in \CFA.
    695 \end{rationale}
    696 
    697 \begin{rationale}
    698 Expression syntax is quoted from the {\c11} standard. The syntax itself defines the precedence and
    699 associativity of operators. The sections are arranged in decreasing order of precedence, with all
    700 operators in a section having the same precedence.
    701 \end{rationale}
    702 
    703 
    704 \subsection{Primary expressions}
    705 
    706 \begin{syntax}
    707 \lhs{primary-expression}
    708 \rhs \nonterm{identifier}
    709 \rhs \nonterm{constant}
    710 \rhs \nonterm{string-literal}
    711 \rhs \lstinline$($ \nonterm{expression} \lstinline$)$
    712 \rhs \nonterm{generic-selection}
    713 \end{syntax}
    714 
    715 \paragraph{Predefined Identifiers}%
    716 \begin{lstlisting}
    717 const int 1;@\use{1}@
    718 const int 0;@\use{0}@
    719 forall( dtype DT ) DT *const 0;
    720 forall( ftype FT ) FT *const 0;
    721 \end{lstlisting}
    722 
    723 \semantics
    724 The \Index{valid interpretation} of an \nonterm{identifier} are given by the visible\index{visible}
    725 declarations of the identifier.
    726 
    727 A \nonterm{constant} or \nonterm{string-literal} has one valid interpretation, which has the type
    728 and value defined by {\c11}. The predefined integer identifiers ``\lstinline$1$'' and
    729 ``\lstinline$0$'' have the integer values 1 and 0, respectively. The other two predefined
    730 ``\lstinline$0$'' identifiers are bound to polymorphic pointer values that, when
    731 specialized\index{specialization} with a data type or function type respectively, produce a null
    732 pointer of that type.
    733 
    734 A parenthesised expression has the same interpretations as the contained \nonterm{expression}.
    735 
    736 \examples
    737 The expression \lstinline$(void *)0$\use{0} specializes the (polymorphic) null pointer to a null
    738 pointer to \lstinline$void$. \lstinline$(const void *)0$ does the same, and also uses a safe
    739 conversion from \lstinline$void *$ to \lstinline$const void *$. In each case, the null pointer
    740 conversion is better\index{best valid interpretations} than the unsafe conversion of the integer
    741 \lstinline$0$ to a pointer.
    742 
    743 \begin{rationale}
    744 Note that the predefined identifiers have addresses.
    745 
    746 \CFA does not have C's concept of ``null pointer constants'', which are not typed values but
    747 special strings of tokens. The C token ``\lstinline$0$'' is an expression of type \lstinline$int$
    748 with the value ``zero'', and it \emph{also} is a null pointer constant. Similarly,
    749 ``\lstinline$(void *)0$ is an expression of type \lstinline$(void *)$ whose value is a null pointer,
    750 and it also is a null pointer constant. However, in C, ``\lstinline$(void *)(void *)0$'' is
    751 \emph{not} a null pointer constant, even though it is null-valued, a pointer, and constant! The
    752 semantics of C expressions contain many special cases to deal with subexpressions that are null
    753 pointer constants.
    754 
    755 \CFA handles these cases through overload resolution. The declaration
    756 \begin{lstlisting}
    757 forall( dtype DT ) DT *const 0;
    758 \end{lstlisting}
    759 means that \lstinline$0$ is a polymorphic object, and contains a value that can have \emph{any}
    760 pointer-to-object type or pointer-to-incomplete type. The only such value is the null pointer.
    761 Therefore the type \emph{alone} is enough to identify a null pointer. Where C defines an operator
    762 with a special case for the null pointer constant, \CFA defines predefined functions with a
    763 polymorphic object parameter.
    764 \end{rationale}
    765 
    766 
    767 \subsubsection{Generic selection}
    768 
    769 \constraints The best interpretation of the controlling expression shall be
    770 unambiguous\index{ambiguous interpretation}, and shall have type compatible with at most one of the
    771 types named in its generic association list. If a generic selection has no \lstinline$default$
    772 generic association, the best interpretation of its controlling expression shall have type
    773 compatible with exactly one of the types named in its generic association list.
    774 
    775 \semantics
    776 A generic selection has the same interpretations as its result expression.
    777 
    778 
    779 \subsection{Postfix operators}
    780 
    781 \begin{syntax}
    782 \lhs{postfix-expression}
    783 \rhs \nonterm{primary-expression}
    784 \rhs \nonterm{postfix-expression} \lstinline$[$ \nonterm{expression} \lstinline$]$
    785 \rhs \nonterm{postfix-expression} \lstinline$($
    786          \nonterm{argument-expression-list}\opt \lstinline$)$
    787 \rhs \nonterm{postfix-expression} \lstinline$.$ \nonterm{identifier}
    788 \rhs \nonterm{postfix-expression} \lstinline$->$ \nonterm{identifier}
    789 \rhs \nonterm{postfix-expression} \lstinline$++$
    790 \rhs \nonterm{postfix-expression} \lstinline$--$
    791 \rhs \lstinline$($ \nonterm{type-name} \lstinline$)$ \lstinline${$ \nonterm{initializer-list} \lstinline$}$
    792 \rhs \lstinline$($ \nonterm{type-name} \lstinline$)$ \lstinline${$ \nonterm{initializer-list} \lstinline$,$ \lstinline$}$
    793 \lhs{argument-expression-list}
    794 \rhs \nonterm{assignment-expression}
    795 \rhs \nonterm{argument-expression-list} \lstinline$,$
    796          \nonterm{assignment-expression}
    797 \end{syntax}
    798 
    799 \rewriterules
    800 \begin{lstlisting}
    801 a[b] @\rewrite@ ?[?]( b, a ) // if a has integer type */@\use{?[?]}@
    802 a[b] @\rewrite@ ?[?]( a, b ) // otherwise
    803 a( ${\em arguments }$ ) @\rewrite@ ?()( a, ${\em arguments} )$@\use{?()}@
    804 a++ @\rewrite@ ?++(&( a ))@\use{?++}@
    805 a-- @\rewrite@ ?--(&( a ))@\use{?--}@
    806 \end{lstlisting}
    807 
    808 
    809 \subsubsection{Array subscripting}
    810 
    811 \begin{lstlisting}
    812 forall( type T ) lvalue T ?[?]( T *, ptrdiff_t );@\use{ptrdiff_t}@
    813 forall( type T ) lvalue _Atomic T ?[?]( _Atomic T *, ptrdiff_t );
    814 forall( type T ) lvalue const T ?[?]( const T *, ptrdiff_t );
    815 forall( type T ) lvalue restrict T ?[?]( restrict T *, ptrdiff_t );
    816 forall( type T ) lvalue volatile T ?[?]( volatile T *, ptrdiff_t );
    817 forall( type T ) lvalue _Atomic const T ?[?]( _Atomic const T *, ptrdiff_t );
    818 forall( type T ) lvalue _Atomic restrict T ?[?]( _Atomic restrict T *, ptrdiff_t );
    819 forall( type T ) lvalue _Atomic volatile T ?[?]( _Atomic volatile T *, ptrdiff_t );
    820 forall( type T ) lvalue const restrict T ?[?]( const restrict T *, ptrdiff_t );
    821 forall( type T ) lvalue const volatile T ?[?]( const volatile T *, ptrdiff_t );
    822 forall( type T ) lvalue restrict volatile T ?[?]( restrict volatile T *, ptrdiff_t );
    823 forall( type T ) lvalue _Atomic const restrict T ?[?]( _Atomic const restrict T *, ptrdiff_t );
    824 forall( type T ) lvalue _Atomic const volatile T ?[?]( _Atomic const volatile T *, ptrdiff_t );
    825 forall( type T ) lvalue _Atomic restrict volatile T ?[?]( _Atomic restrict volatile T *, ptrdiff_t );
    826 forall( type T ) lvalue const restrict volatile T ?[?]( const restrict volatile T *, ptrdiff_t );
    827 forall( type T ) lvalue _Atomic const restrict volatile T ?[?]( _Atomic const restrict volatile T *, ptrdiff_t );
    828 \end{lstlisting}
    829 \semantics
    830 The interpretations of subscript expressions are the interpretations of the corresponding function
    831 call expressions.
    832 \begin{rationale}
    833 C defines subscripting as pointer arithmetic in a way that makes \lstinline$a[i]$ and
    834 \lstinline$i[a]$ equivalent. \CFA provides the equivalence through a rewrite rule to reduce the
    835 number of overloadings of \lstinline$?[?]$.
    836 
    837 Subscript expressions are rewritten as function calls that pass the first parameter by value. This
    838 is somewhat unfortunate, since array-like types tend to be large. The alternative is to use the
    839 rewrite rule ``\lstinline$a[b]$ \rewrite \lstinline$?[?](&(a), b)$''. However, C semantics forbid
    840 this approach: the \lstinline$a$ in ``\lstinline$a[b]$'' can be an arbitrary pointer value, which
    841 does not have an address.
    842 
    843 The repetitive form of the predefined identifiers shows up a deficiency\index{deficiencies!pointers
    844  to qualified types} of \CFA's type system. Type qualifiers are not included in type values, so
    845 polymorphic functions that take pointers to arbitrary types often come in one flavor for each
    846 possible qualification of the pointed-at type.
    847 \end{rationale}
    848 
    849 
    850 \subsubsection{Function calls}
    851 
    852 \semantics
    853 A \define{function designator} is an interpretation of an expression that has function type. The
    854 \nonterm{postfix-expression} in a function call may have some interpretations that are function
    855 designators and some that are not.
    856 
    857 For those interpretations of the \nonterm{postfix-expression} that are not function designators, the
    858 expression is rewritten and becomes a call of a function named ``\lstinline$?()$''. The valid
    859 interpretations of the rewritten expression are determined in the manner described below.
    860 
    861 Each combination of function designators and argument interpretations is considered. For those
    862 interpretations of the \nonterm{postfix-expression} that are \Index{monomorphic function}
    863 designators, the combination has a \Index{valid interpretation} if the function designator accepts
    864 the number of arguments given, and each argument interpretation matches the corresponding explicit
    865 parameter:
    866 \begin{itemize}
    867 \item
    868 if the argument corresponds to a parameter in the function designator's prototype, the argument
    869 interpretation must have the same type as the corresponding parameter, or be implicitly convertible
    870 to the parameter's type
    871 \item
    872 if the function designator's type does not include a prototype or if the argument corresponds to
    873 ``\lstinline$...$'' in a prototype, a \Index{default argument promotion} is applied to it.
    874 \end{itemize}
    875 The type of the valid interpretation is the return type of the function designator.
    876 
    877 For those combinations where the interpretation of the \nonterm{postfix-expression} is a
    878 \Index{polymorphic function} designator and the function designator accepts the number of arguments
    879 given, there shall be at least one set of \define{implicit argument}s for the implicit parameters
    880 such that
    881 \begin{itemize}
    882 \item
    883 If the declaration of the implicit parameter uses \Index{type-class} \lstinline$type$\use{type}, the
    884 implicit argument must be an object type; if it uses \lstinline$dtype$, the implicit argument must
    885 be an object type or an incomplete type; and if it uses \lstinline$ftype$, the implicit argument
    886 must be a function type.
    887 
    888 \item
    889 if an explicit parameter's type uses any implicit parameters, then the corresponding explicit
    890 argument must have a type that is (or can be safely converted\index{safe conversion} to) the type
    891 produced by substituting the implicit arguments for the implicit parameters in the explicit
    892 parameter type.
    893 
    894 \item
    895 the remaining explicit arguments must match the remaining explicit parameters, as described for
    896 monomorphic function designators.
    897 
    898 \item
    899 for each \Index{assertion parameter} in the function designator's type, there must be an object or
    900 function with the same identifier that is visible at the call site and whose type is compatible with
    901 or can be specialized to the type of the assertion declaration.
    902 \end{itemize}
    903 There is a valid interpretation for each such set of implicit parameters. The type of each valid
    904 interpretation is the return type of the function designator with implicit parameter values
    905 substituted for the implicit arguments.
    906 
    907 A valid interpretation is ambiguous\index{ambiguous interpretation} if the function designator or
    908 any of the argument interpretations is ambiguous.
    909 
    910 Every valid interpretation whose return type is not compatible with any other valid interpretation's
    911 return type is an interpretation of the function call expression.
    912 
    913 Every set of valid interpretations that have mutually compatible\index{compatible type} result types
    914 also produces an interpretation of the function call expression. The type of the interpretation is
    915 the \Index{composite type} of the types of the valid interpretations, and the value of the
    916 interpretation is that of the \Index{best valid interpretation}.
    917 \begin{rationale}
    918 One desirable property of a polymorphic programming language is \define{generalizability}: the
    919 ability to replace an abstraction with a more general but equivalent abstraction without requiring
    920 changes in any of the uses of the original\cite{Cormack90}. For instance, it should be possible to
    921 replace a function ``\lstinline$int f( int );$'' with ``\lstinline$forall( type T ) T f( T );$''
    922 without affecting any calls of \lstinline$f$.
    923 
    924 \CFA\index{deficiencies!generalizability} does not fully possess this property, because
    925 \Index{unsafe conversion} are not done when arguments are passed to polymorphic parameters.
    926 Consider
    927 \begin{lstlisting}
    928 float g( float, float );
    929 int i;
    930 float f;
    931 double d;
    932 f = g( f, f );  // (1)
    933 f = g( i, f );  // (2) (safe conversion to float)
    934 f = g( d, f );  // (3) (unsafe conversion to float)
    935 \end{lstlisting}
    936 If \lstinline$g$ was replaced by ``\lstinline$forall( type T ) T g( T, T );$'', the first and second
    937 calls would be unaffected, but the third would change: \lstinline$f$ would be converted to
    938 \lstinline$double$, and the result would be a \lstinline$double$.
    939 
    940 Another example is the function ``\lstinline$void h( int *);$''. This function can be passed a
    941 \lstinline$void *$ argument, but the generalization ``\lstinline$forall( type T ) void h( T *);$''
    942 can not. In this case, \lstinline$void$ is not a valid value for \lstinline$T$ because it is not an
    943 object type. If unsafe conversions were allowed, \lstinline$T$ could be inferred to be \emph{any}
    944 object type, which is undesirable.
    945 \end{rationale}
    946 
    947 \examples
    948 A function called ``\lstinline$?()$'' might be part of a numerical differentiation package.
    949 \begin{lstlisting}
    950 extern type Derivative;
    951 extern double ?()( Derivative, double );
    952 extern Derivative derivative_of( double (*f)( double ) );
    953 extern double sin( double );
    954 
    955 Derivative sin_dx = derivative_of( sin );
    956 double d;
    957 d = sin_dx( 12.9 );
    958 \end{lstlisting}
    959 Here, the only interpretation of \lstinline$sin_dx$ is as an object of type \lstinline$Derivative$.
    960 For that interpretation, the function call is treated as ``\lstinline$?()( sin_dx, 12.9 )$''.
    961 \begin{lstlisting}
    962 int f( long );          // (1)
    963 int f( int, int );      // (2)
    964 int f( int *);          // (3)
    965 
    966 int i = f( 5 );         // calls (1)
    967 \end{lstlisting}
    968 Function (1) provides a valid interpretation of ``\lstinline$f( 5 )$'', using an implicit
    969 \lstinline$int$ to \lstinline$long$ conversion. The other functions do not, since the second
    970 requires two arguments, and since there is no implicit conversion from \lstinline$int$ to
    971 \lstinline$int *$ that could be used with the third function.
    972 
    973 \begin{lstlisting}
    974 forall( type T ) T h( T );
    975 double d = h( 1.5 );
    976 \end{lstlisting}
    977 ``\lstinline$1.5$'' is a \lstinline$double$ constant, so \lstinline$T$ is inferred to be
    978 \lstinline$double$, and the result of the function call is a \lstinline$double$.
    979 
    980 \begin{lstlisting}
    981 forall( type T, type U ) void g( T, U );        // (4)
    982 forall( type T ) void g( T, T );                        // (5)
    983 forall( type T ) void g( T, long );                     // (6)
    984 void g( long, long );                                           // (7)
    985 double d;
    986 int i;
    987 int *p;
    988 
    989 g( d, d );                      // calls (5)
    990 g( d, i );                      // calls (6)
    991 g( i, i );                      // calls (7)
    992 g( i, p );                      // calls (4)
    993 \end{lstlisting}
    994 The first call has valid interpretations for all four versions of \lstinline$g$. (6) and (7) are
    995 discarded because they involve unsafe \lstinline$double$-to-\lstinline$long$ conversions. (5) is
    996 chosen because it is less polymorphic than (4).
    997 
    998 For the second call, (7) is again discarded. Of the remaining interpretations for (4), (5), and (6)
    999 (with \lstinline$i$ converted to \lstinline$long$), (6) is chosen because it is the least
    1000 polymorphic.
    1001 
    1002 The third call has valid interpretations for all of the functions; (7) is chosen since it is not
    1003 polymorphic at all.
    1004 
    1005 The fourth call has no interpretation for (5), because its arguments must have compatible type. (4)
    1006 is chosen because it does not involve unsafe conversions.
    1007 \begin{lstlisting}
    1008 forall( type T ) T min( T, T );
    1009 double max( double, double );
    1010 context min_max( T ) {@\impl{min_max}@
    1011         T min( T, T );
    1012         T max( T, T );
    1013 }
    1014 forall( type U | min_max( U ) ) void shuffle( U, U );
    1015 shuffle(9, 10);
    1016 \end{lstlisting}
    1017 The only possibility for \lstinline$U$ is \lstinline$double$, because that is the type used in the
    1018 only visible \lstinline$max$ function. 9 and 10 must be converted to \lstinline$double$, and
    1019 \lstinline$min$ must be specialized with \lstinline$T$ bound to \lstinline$double$.
    1020 \begin{lstlisting}
    1021 extern void q( int );           // (8)
    1022 extern void q( void * );        // (9)
    1023 extern void r();
    1024 q( 0 );
    1025 r( 0 );
    1026 \end{lstlisting}
    1027 The \lstinline$int 0$ could be passed to (8), or the \lstinline$(void *)$ \Index{specialization} of
    1028 the null pointer\index{null pointer} \lstinline$0$\use{0} could be passed to (9). The former is
    1029 chosen because the \lstinline$int$ \lstinline$0$ is \Index{less polymorphic}. For
    1030 the same reason, \lstinline$int$ \lstinline$0$ is passed to \lstinline$r()$, even though it has
    1031 \emph{no} declared parameter types.
    1032 
    1033 
    1034 \subsubsection{Structure and union members}
    1035 
    1036 \semantics In the member selection expression ``\lstinline$s$.\lstinline$m$'', there shall be at
    1037 least one interpretation of \lstinline$s$ whose type is a structure type or union type containing a
    1038 member named \lstinline$m$. If two or more interpretations of \lstinline$s$ have members named
    1039 \lstinline$m$ with mutually compatible types, then the expression has an \Index{ambiguous
    1040 interpretation} whose type is the composite type of the types of the members. If an interpretation
    1041 of \lstinline$s$ has a member \lstinline$m$ whose type is not compatible with any other
    1042 \lstinline$s$'s \lstinline$m$, then the expression has an interpretation with the member's type. The
    1043 expression has no other interpretations.
    1044 
    1045 The expression ``\lstinline$p->m$'' has the same interpretations as the expression
    1046 ``\lstinline$(*p).m$''.
    1047 
    1048 
    1049 \subsubsection{Postfix increment and decrement operators}
    1050 
    1051 \begin{lstlisting}
    1052 _Bool ?++( volatile _Bool * ),
    1053         ?++( _Atomic volatile _Bool * );
    1054 char ?++( volatile char * ),
    1055         ?++( _Atomic volatile char * );
    1056 signed char ?++( volatile signed char * ),
    1057         ?++( _Atomic volatile signed char * );
    1058 unsigned char ?++( volatile signed char * ),
    1059         ?++( _Atomic volatile signed char * );
    1060 short int ?++( volatile short int * ),
    1061         ?++( _Atomic volatile short int * );
    1062 unsigned short int ?++( volatile unsigned short int * ),
    1063         ?++( _Atomic volatile unsigned short int * );
    1064 int ?++( volatile int * ),
    1065         ?++( _Atomic volatile int * );
    1066 unsigned int ?++( volatile unsigned int * ),
    1067         ?++( _Atomic volatile unsigned int * );
    1068 long int ?++( volatile long int * ),
    1069         ?++( _Atomic volatile long int * );
    1070 long unsigned int ?++( volatile long unsigned int * ),
    1071         ?++( _Atomic volatile long unsigned int * );
    1072 long long int ?++( volatile long long int * ),
    1073         ?++( _Atomic volatile long long int * );
    1074 long long unsigned ?++( volatile long long unsigned int * ),
    1075         ?++( _Atomic volatile long long unsigned int * );
    1076 float ?++( volatile float * ),
    1077         ?++( _Atomic volatile float * );
    1078 double ?++( volatile double * ),
    1079         ?++( _Atomic volatile double * );
    1080 long double ?++( volatile long double * ),
    1081         ?++( _Atomic volatile long double * );
    1082 
    1083 forall( type T ) T * ?++( T * restrict volatile * ),
    1084         * ?++( T * _Atomic restrict volatile * );
    1085 
    1086 forall( type T ) _Atomic T * ?++( _Atomic T * restrict volatile * ),
    1087         * ?++( _Atomic T * _Atomic restrict volatile * );
    1088 
    1089 forall( type T ) const T * ?++( const T * restrict volatile * ),
    1090         * ?++( const T * _Atomic restrict volatile * );
    1091 
    1092 forall( type T ) volatile T * ?++( volatile T * restrict volatile * ),
    1093         * ?++( volatile T * _Atomic restrict volatile * );
    1094 
    1095 forall( type T ) restrict T * ?++( restrict T * restrict volatile * ),
    1096         * ?++( restrict T * _Atomic restrict volatile * );
    1097 
    1098 forall( type T ) _Atomic const T * ?++( _Atomic const T * restrict volatile * ),
    1099         * ?++( _Atomic const T * _Atomic restrict volatile * );
    1100 
    1101 forall( type T ) _Atomic restrict T * ?++( _Atomic restrict T * restrict volatile * ),
    1102         * ?++( _Atomic restrict T * _Atomic restrict volatile * );
    1103 
    1104 forall( type T ) _Atomic volatile T * ?++( _Atomic volatile T * restrict volatile * ),
    1105         * ?++( _Atomic volatile T * _Atomic restrict volatile * );
    1106 
    1107 forall( type T ) const restrict T * ?++( const restrict T * restrict volatile * ),
    1108         * ?++( const restrict T * _Atomic restrict volatile * );
    1109 
    1110 forall( type T ) const volatile T * ?++( const volatile T * restrict volatile * ),
    1111         * ?++( const volatile T * _Atomic restrict volatile * );
    1112 
    1113 forall( type T ) restrict volatile T * ?++( restrict volatile T * restrict volatile * ),
    1114         * ?++( restrict volatile T * _Atomic restrict volatile * );
    1115 
    1116 forall( type T ) _Atomic const restrict T * ?++( _Atomic const restrict T * restrict volatile * ),
    1117         * ?++( _Atomic const restrict T * _Atomic restrict volatile * );
    1118 
    1119 forall( type T ) _Atomic const volatile T * ?++( _Atomic const volatile T * restrict volatile * ),
    1120         * ?++( _Atomic const volatile T * _Atomic restrict volatile * );
    1121 
    1122 forall( type T ) _Atomic restrict volatile T * ?++( _Atomic restrict volatile T * restrict volatile * ),
    1123         * ?++( _Atomic restrict volatile T * _Atomic restrict volatile * );
    1124 
    1125 forall( type T ) const restrict volatile T * ?++( const restrict volatile T * restrict volatile * ),
    1126         * ?++( const restrict volatile T * _Atomic restrict volatile * );
    1127 
    1128 forall( type T ) _Atomic const restrict volatile T * ?++( _Atomic const restrict volatile T * restrict volatile * ),
    1129         * ?++( _Atomic const restrict volatile T * _Atomic restrict volatile * );
    1130 
    1131 _Bool ?--( volatile _Bool * ),
    1132         ?--( _Atomic volatile _Bool * );
    1133 char ?--( volatile char * ),
    1134         ?--( _Atomic volatile char * );
    1135 signed char ?--( volatile signed char * ),
    1136         ?--( _Atomic volatile signed char * );
    1137 unsigned char ?--( volatile signed char * ),
    1138         ?--( _Atomic volatile signed char * );
    1139 short int ?--( volatile short int * ),
    1140         ?--( _Atomic volatile short int * );
    1141 unsigned short int ?--( volatile unsigned short int * ),
    1142         ?--( _Atomic volatile unsigned short int * );
    1143 int ?--( volatile int * ),
    1144         ?--( _Atomic volatile int * );
    1145 unsigned int ?--( volatile unsigned int * ),
    1146         ?--( _Atomic volatile unsigned int * );
    1147 long int ?--( volatile long int * ),
    1148         ?--( _Atomic volatile long int * );
    1149 long unsigned int ?--( volatile long unsigned int * ),
    1150         ?--( _Atomic volatile long unsigned int * );
    1151 long long int ?--( volatile long long int * ),
    1152         ?--( _Atomic volatile long long int * );
    1153 long long unsigned ?--( volatile long long unsigned int * ),
    1154         ?--( _Atomic volatile long long unsigned int * );
    1155 float ?--( volatile float * ),
    1156         ?--( _Atomic volatile float * );
    1157 double ?--( volatile double * ),
    1158         ?--( _Atomic volatile double * );
    1159 long double ?--( volatile long double * ),
    1160         ?--( _Atomic volatile long double * );
    1161 
    1162 forall( type T ) T * ?--( T * restrict volatile * ),
    1163         * ?--( T * _Atomic restrict volatile * );
    1164 
    1165 forall( type T ) _Atomic T * ?--( _Atomic T * restrict volatile * ),
    1166         * ?--( _Atomic T * _Atomic restrict volatile * );
    1167 
    1168 forall( type T ) const T * ?--( const T * restrict volatile * ),
    1169         * ?--( const T * _Atomic restrict volatile * );
    1170 
    1171 forall( type T ) volatile T * ?--( volatile T * restrict volatile * ),
    1172         * ?--( volatile T * _Atomic restrict volatile * );
    1173 
    1174 forall( type T ) restrict T * ?--( restrict T * restrict volatile * ),
    1175         * ?--( restrict T * _Atomic restrict volatile * );
    1176 
    1177 forall( type T ) _Atomic const T * ?--( _Atomic const T * restrict volatile * ),
    1178         * ?--( _Atomic const T * _Atomic restrict volatile * );
    1179 
    1180 forall( type T ) _Atomic restrict T * ?--( _Atomic restrict T * restrict volatile * ),
    1181         * ?--( _Atomic restrict T * _Atomic restrict volatile * );
    1182 
    1183 forall( type T ) _Atomic volatile T * ?--( _Atomic volatile T * restrict volatile * ),
    1184         * ?--( _Atomic volatile T * _Atomic restrict volatile * );
    1185 
    1186 forall( type T ) const restrict T * ?--( const restrict T * restrict volatile * ),
    1187         * ?--( const restrict T * _Atomic restrict volatile * );
    1188 
    1189 forall( type T ) const volatile T * ?--( const volatile T * restrict volatile * ),
    1190         * ?--( const volatile T * _Atomic restrict volatile * );
    1191 
    1192 forall( type T ) restrict volatile T * ?--( restrict volatile T * restrict volatile * ),
    1193         * ?--( restrict volatile T * _Atomic restrict volatile * );
    1194 
    1195 forall( type T ) _Atomic const restrict T * ?--( _Atomic const restrict T * restrict volatile * ),
    1196         * ?--( _Atomic const restrict T * _Atomic restrict volatile * );
    1197 
    1198 forall( type T ) _Atomic const volatile T * ?--( _Atomic const volatile T * restrict volatile * ),
    1199         * ?--( _Atomic const volatile T * _Atomic restrict volatile * );
    1200 
    1201 forall( type T ) _Atomic restrict volatile T * ?--( _Atomic restrict volatile T * restrict volatile * ),
    1202         * ?--( _Atomic restrict volatile T * _Atomic restrict volatile * );
    1203 
    1204 forall( type T ) const restrict volatile T * ?--( const restrict volatile T * restrict volatile * ),
    1205         * ?--( const restrict volatile T * _Atomic restrict volatile * );
    1206 
    1207 forall( type T ) _Atomic const restrict volatile T * ?--( _Atomic const restrict volatile T * restrict volatile * ),
    1208         * ?--( _Atomic const restrict volatile T * _Atomic restrict volatile * );
    1209 \end{lstlisting}
    1210 For every extended integer type \lstinline$X$ there exist
    1211 % Don't use predefined: keep this out of prelude.cf.
    1212 \begin{lstlisting}
    1213 X ?++( volatile X * ), ?++( _Atomic volatile X * ),
    1214   ?--( volatile X * ), ?--( _Atomic volatile X * );
    1215 \end{lstlisting}
    1216 For every complete enumerated type \lstinline$E$ there exist
    1217 % Don't use predefined: keep this out of prelude.cf.
    1218 \begin{lstlisting}
    1219 E ?++( volatile E * ), ?++( _Atomic volatile E * ),
    1220   ?--( volatile E * ), ?--( _Atomic volatile E * );
    1221 \end{lstlisting}
    1222 
    1223 \begin{rationale}
    1224 Note that ``\lstinline$++$'' and ``\lstinline$--$'' are rewritten as function calls that are given a
    1225 pointer to that operand. (This is true of all operators that modify an operand.) As Hamish Macdonald
    1226 has pointed out, this forces the modified operand of such expressions to be an lvalue. This
    1227 partially enforces the C semantic rule that such operands must be \emph{modifiable} lvalues.
    1228 \end{rationale}
    1229 
    1230 \begin{rationale}
    1231 In C, a semantic rule requires that pointer operands of increment and decrement be pointers to
    1232 object types. Hence, \lstinline$void *$ objects cannot be incremented. In \CFA, the restriction
    1233 follows from the use of a \lstinline$type$ parameter in the predefined function definitions, as
    1234 opposed to \lstinline$dtype$, since only object types can be inferred arguments corresponding to the
    1235 type parameter \lstinline$T$.
    1236 \end{rationale}
    1237 
    1238 \semantics
    1239 First, each interpretation of the operand of an increment or decrement expression is considered
    1240 separately. For each interpretation that is a bit-field or is declared with the
    1241 \lstinline$register$\index{register@{\lstinline$register$}} \index{Itorage-class specifier}, the
    1242 expression has one valid interpretation, with the type of the operand, and the expression is
    1243 ambiguous if the operand is.
    1244 
    1245 For the remaining interpretations, the expression is rewritten, and the interpretations of the
    1246 expression are the interpretations of the corresponding function call. Finally, all interpretations
    1247 of the expression produced for the different interpretations of the operand are combined to produce
    1248 the interpretations of the expression as a whole; where interpretations have compatible result
    1249 types, the best interpretations are selected in the manner described for function call expressions.
    1250 
    1251 \examples
    1252 \begin{lstlisting}
    1253 volatile short int vs;  vs++; // rewritten as ?++( &(vs) )
    1254 short int s;                    s++;
    1255 const short int cs;             cs++;
    1256 _Atomic short int as;   as++;
    1257 \end{lstlisting}
    1258 \begin{sloppypar}
    1259 Since \lstinline$&(vs)$ has type \lstinline$volatile short int *$, the best valid interpretation of
    1260 \lstinline$vs++$ calls the \lstinline$?++$ function with the \lstinline$volatile short *$ parameter.
    1261 \lstinline$s++$ does the same, applying the safe conversion from \lstinline$short int *$ to
    1262 \lstinline$volatile short int *$. Note that there is no conversion that adds an \lstinline$_Atomic$
    1263 qualifier, so the \lstinline$_Atomic volatile short int$ overloading does not provide a valid
    1264 interpretation.
    1265 \end{sloppypar}
    1266 
    1267 There is no safe conversion from \lstinline$const short int *$ to \lstinline$volatile short int *$,
    1268 and no \lstinline$?++$ function that accepts a \lstinline$const *$ parameter, so \lstinline$cs++$
    1269 has no valid interpretations.
    1270 
    1271 The best valid interpretation of \lstinline$as++$ calls the \lstinline$short ?++$ function with the
    1272 \lstinline$_Atomic volatile short int *$ parameter, applying a safe conversion to add the
    1273 \lstinline$volatile$ qualifier.
    1274 
    1275 \begin{lstlisting}
    1276 char * const restrict volatile * restrict volatile pqpc; pqpc++
    1277 char * * restrict volatile ppc; ppc++;
    1278 \end{lstlisting}
    1279 Since \lstinline$&(pqpc)$ has type \lstinline$char * const restrict volatile * restrict volatile *$,
    1280 the best valid interpretation of \lstinline$pqpc++$ calls the polymorphic \lstinline$?++$ function
    1281 with the \lstinline$const restrict volatile T * restrict volatile *$ parameter, inferring
    1282 \lstinline$T$ to be \lstinline$char *$.
    1283 
    1284 \begin{sloppypar}
    1285 \lstinline$ppc++$ calls the same function, again inferring \lstinline$T$ to be \lstinline$char *$,
    1286 and using the safe conversions from \lstinline$T$ to \lstinline$T const restrict volatile$.
    1287 \end{sloppypar}
    1288 
    1289 \begin{rationale}
    1290 Increment and decrement expressions show up a deficiency of \CFA's type system. There is no such
    1291 thing as a pointer to a register object or bit-field\index{deficiencies!pointers to bit-fields}.
    1292 Therefore, there is no way to define a function that alters them, and hence no way to define
    1293 increment and decrement functions for them. As a result, the semantics of increment and decrement
    1294 expressions must treat them specially. This holds true for all of the operators that may modify
    1295 such objects.
    1296 \end{rationale}
    1297 
    1298 \begin{rationale}
    1299 The polymorphic overloadings for pointer increment and decrement can be understood by considering
    1300 increasingly complex types.
    1301 \begin{enumerate}
    1302 \item
    1303 ``\lstinline$char * p; p++;$''. The argument to \lstinline$?++$ has type \lstinline$char * *$, and
    1304 the result has type \lstinline$char *$. The expression would be valid if \lstinline$?++$ were
    1305 declared by
    1306 \begin{lstlisting}
    1307 forall( type T ) T * ?++( T * * );
    1308 \end{lstlisting}
    1309 with \lstinline$T$ inferred to be \lstinline$char$.
    1310 
    1311 \item
    1312 ``\lstinline$char *restrict volatile qp; qp++$''. The result again has type \lstinline$char *$, but
    1313 the argument now has type \lstinline$char *restrict volatile *$, so it cannot be passed to the
    1314 hypothetical function declared in point 1. Hence the actual predefined function is
    1315 \begin{lstlisting}
    1316 forall( type T ) T * ?++( T * restrict volatile * );
    1317 \end{lstlisting}
    1318 which also accepts a \lstinline$char * *$ argument, because of the safe conversions that add
    1319 \lstinline$volatile$ and \lstinline$restrict$ qualifiers. (The parameter is not const-qualified, so
    1320 constant pointers cannot be incremented.)
    1321 
    1322 \item
    1323 ``\lstinline$char *_Atomic ap; ap++$''. The result again has type \lstinline$char *$, but no safe
    1324 conversion adds an \lstinline$_Atomic$ qualifier, so the function in point 2 is not applicable. A
    1325 separate overloading of \lstinline$?++$ is required.
    1326 
    1327 \item
    1328 ``\lstinline$char const volatile * pq; pq++$''. Here the result has type
    1329 \lstinline$char const volatile *$, so a new overloading is needed:
    1330 \begin{lstlisting}
    1331 forall( type T ) T const volatile * ?++( T const volatile *restrict volatile * );
    1332 \end{lstlisting}
    1333 One overloading is needed for each combination of qualifiers in the pointed-at
    1334 type\index{deficiencies!pointers to qualified types}.
    1335  
    1336 \item
    1337 ``\lstinline$float *restrict * prp; prp++$''. The \lstinline$restrict$ qualifier is handled just
    1338 like \lstinline$const$ and \lstinline$volatile$ in the previous case:
    1339 \begin{lstlisting}
    1340 forall( type T ) T restrict * ?++( T restrict *restrict volatile * );
    1341 \end{lstlisting}
    1342 with \lstinline$T$ inferred to be \lstinline$float *$. This looks odd, because {\c11} contains a
    1343 constraint that requires restrict-qualified types to be pointer-to-object types, and \lstinline$T$
    1344 is not syntactically a pointer type. \CFA loosens the constraint.
    1345 \end{enumerate}
    1346 \end{rationale}
    1347 
    1348 
    1349 \subsubsection{Compound literals}
    1350 
    1351 \semantics
    1352 A compound literal has one interpretation, with the type given by the \nonterm{type-name} of the
    1353 compound literal.
    1354 
    1355 
    1356 \subsection{Unary operators}
    1357 
    1358 \begin{syntax}
    1359 \lhs{unary-expression}
    1360 \rhs \nonterm{postfix-expression}
    1361 \rhs \lstinline$++$ \nonterm{unary-expression}
    1362 \rhs \lstinline$--$ \nonterm{unary-expression}
    1363 \rhs \nonterm{unary-operator} \nonterm{cast-expression}
    1364 \rhs \lstinline$sizeof$ \nonterm{unary-expression}
    1365 \rhs \lstinline$sizeof$ \lstinline$($ \nonterm{type-name} \lstinline$)$
    1366 \lhs{unary-operator} one of \rhs \lstinline$&$ \lstinline$*$ \lstinline$+$ \lstinline$-$ \lstinline$~$ \lstinline$!$
    1367 \end{syntax}
    1368 
    1369 \rewriterules
    1370 \begin{lstlisting}
    1371 *a      @\rewrite@ *?(a) @\use{*?}@
    1372 +a      @\rewrite@ +?(a) @\use{+?}@
    1373 -a      @\rewrite@ -?(a) @\use{-?}@
    1374 ~a      @\rewrite@ ~?(a) @\use{~?}@
    1375 !a      @\rewrite@ !?(a) @\use{"!?}@
    1376 ++a     @\rewrite@ ++?(&(a)) @\use{++?}@
    1377 --a     @\rewrite@ --?(&(a)) @\use{--?}@
    1378 \end{lstlisting}
    1379 
    1380 
    1381 \subsubsection{Prefix increment and decrement operators}
    1382 
    1383 \begin{lstlisting}
    1384 _Bool ++?( volatile _Bool * ),
    1385         ++?( _Atomic volatile _Bool * );
    1386 char ++?( volatile char * ),
    1387         ++?( _Atomic volatile char * );
    1388 signed char ++?( volatile signed char * ),
    1389         ++?( _Atomic volatile signed char * );
    1390 unsigned char ++?( volatile signed char * ),
    1391         ++?( _Atomic volatile signed char * );
    1392 short int ++?( volatile short int * ),
    1393         ++?( _Atomic volatile short int * );
    1394 unsigned short int ++?( volatile unsigned short int * ),
    1395         ++?( _Atomic volatile unsigned short int * );
    1396 int ++?( volatile int * ),
    1397         ++?( _Atomic volatile int * );
    1398 unsigned int ++?( volatile unsigned int * ),
    1399         ++?( _Atomic volatile unsigned int * );
    1400 long int ++?( volatile long int * ),
    1401         ++?( _Atomic volatile long int * );
    1402 long unsigned int ++?( volatile long unsigned int * ),
    1403         ++?( _Atomic volatile long unsigned int * );
    1404 long long int ++?( volatile long long int * ),
    1405         ++?( _Atomic volatile long long int * );
    1406 long long unsigned ++?( volatile long long unsigned int * ),
    1407         ++?( _Atomic volatile long long unsigned int * );
    1408 float ++?( volatile float * ),
    1409         ++?( _Atomic volatile float * );
    1410 double ++?( volatile double * ),
    1411         ++?( _Atomic volatile double * );
    1412 long double ++?( volatile long double * ),
    1413         ++?( _Atomic volatile long double * );
    1414 
    1415 forall( type T ) T * ++?( T * restrict volatile * ),
    1416         * ++?( T * _Atomic restrict volatile * );
    1417 
    1418 forall( type T ) _Atomic T * ++?( _Atomic T * restrict volatile * ),
    1419         * ++?( _Atomic T * _Atomic restrict volatile * );
    1420 
    1421 forall( type T ) const T * ++?( const T * restrict volatile * ),
    1422         * ++?( const T * _Atomic restrict volatile * );
    1423 
    1424 forall( type T ) volatile T * ++?( volatile T * restrict volatile * ),
    1425         * ++?( volatile T * _Atomic restrict volatile * );
    1426 
    1427 forall( type T ) restrict T * ++?( restrict T * restrict volatile * ),
    1428         * ++?( restrict T * _Atomic restrict volatile * );
    1429 
    1430 forall( type T ) _Atomic const T * ++?( _Atomic const T * restrict volatile * ),
    1431         * ++?( _Atomic const T * _Atomic restrict volatile * );
    1432 
    1433 forall( type T ) _Atomic volatile T * ++?( _Atomic volatile T * restrict volatile * ),
    1434         * ++?( _Atomic volatile T * _Atomic restrict volatile * );
    1435 
    1436 forall( type T ) _Atomic restrict T * ++?( _Atomic restrict T * restrict volatile * ),
    1437         * ++?( _Atomic restrict T * _Atomic restrict volatile * );
    1438 
    1439 forall( type T ) const volatile T * ++?( const volatile T * restrict volatile * ),
    1440         * ++?( const volatile T * _Atomic restrict volatile * );
    1441 
    1442 forall( type T ) const restrict T * ++?( const restrict T * restrict volatile * ),
    1443         * ++?( const restrict T * _Atomic restrict volatile * );
    1444 
    1445 forall( type T ) restrict volatile T * ++?( restrict volatile T * restrict volatile * ),
    1446         * ++?( restrict volatile T * _Atomic restrict volatile * );
    1447 
    1448 forall( type T ) _Atomic const volatile T * ++?( _Atomic const volatile T * restrict volatile * ),
    1449         * ++?( _Atomic const volatile T * _Atomic restrict volatile * );
    1450 
    1451 forall( type T ) _Atomic const restrict T * ++?( _Atomic const restrict T * restrict volatile * ),
    1452         * ++?( _Atomic const restrict T * _Atomic restrict volatile * );
    1453 
    1454 forall( type T ) _Atomic restrict volatile T * ++?( _Atomic restrict volatile T * restrict volatile * ),
    1455         * ++?( _Atomic restrict volatile T * _Atomic restrict volatile * );
    1456 
    1457 forall( type T ) const restrict volatile T * ++?( const restrict volatile T * restrict volatile * ),
    1458         * ++?( const restrict volatile T * _Atomic restrict volatile * );
    1459 
    1460 forall( type T ) _Atomic const restrict volatile T * ++?( _Atomic const restrict volatile T * restrict volatile * ),
    1461         * ++?( _Atomic const restrict volatile T * _Atomic restrict volatile * );
    1462 
    1463 _Bool --?( volatile _Bool * ),
    1464         --?( _Atomic volatile _Bool * );
    1465 char --?( volatile char * ),
    1466         --?( _Atomic volatile char * );
    1467 signed char --?( volatile signed char * ),
    1468         --?( _Atomic volatile signed char * );
    1469 unsigned char --?( volatile signed char * ),
    1470         --?( _Atomic volatile signed char * );
    1471 short int --?( volatile short int * ),
    1472         --?( _Atomic volatile short int * );
    1473 unsigned short int --?( volatile unsigned short int * ),
    1474         --?( _Atomic volatile unsigned short int * );
    1475 int --?( volatile int * ),
    1476         --?( _Atomic volatile int * );
    1477 unsigned int --?( volatile unsigned int * ),
    1478         --?( _Atomic volatile unsigned int * );
    1479 long int --?( volatile long int * ),
    1480         --?( _Atomic volatile long int * );
    1481 long unsigned int --?( volatile long unsigned int * ),
    1482         --?( _Atomic volatile long unsigned int * );
    1483 long long int --?( volatile long long int * ),
    1484         --?( _Atomic volatile long long int * );
    1485 long long unsigned --?( volatile long long unsigned int * ),
    1486         --?( _Atomic volatile long long unsigned int * );
    1487 float --?( volatile float * ),
    1488         --?( _Atomic volatile float * );
    1489 double --?( volatile double * ),
    1490         --?( _Atomic volatile double * );
    1491 long double --?( volatile long double * ),
    1492         --?( _Atomic volatile long double * );
    1493 
    1494 forall( type T ) T * --?( T * restrict volatile * ),
    1495         * --?( T * _Atomic restrict volatile * );
    1496 
    1497 forall( type T ) _Atomic T * --?( _Atomic T * restrict volatile * ),
    1498         * --?( _Atomic T * _Atomic restrict volatile * );
    1499 
    1500 forall( type T ) const T * --?( const T * restrict volatile * ),
    1501         * --?( const T * _Atomic restrict volatile * );
    1502 
    1503 forall( type T ) volatile T * --?( volatile T * restrict volatile * ),
    1504         * --?( volatile T * _Atomic restrict volatile * );
    1505 
    1506 forall( type T ) restrict T * --?( restrict T * restrict volatile * ),
    1507         * --?( restrict T * _Atomic restrict volatile * );
    1508 
    1509 forall( type T ) _Atomic const T * --?( _Atomic const T * restrict volatile * ),
    1510         * --?( _Atomic const T * _Atomic restrict volatile * );
    1511 
    1512 forall( type T ) _Atomic volatile T * --?( _Atomic volatile T * restrict volatile * ),
    1513         * --?( _Atomic volatile T * _Atomic restrict volatile * );
    1514 
    1515 forall( type T ) _Atomic restrict T * --?( _Atomic restrict T * restrict volatile * ),
    1516         * --?( _Atomic restrict T * _Atomic restrict volatile * );
    1517 
    1518 forall( type T ) const volatile T * --?( const volatile T * restrict volatile * ),
    1519         * --?( const volatile T * _Atomic restrict volatile * );
    1520 
    1521 forall( type T ) const restrict T * --?( const restrict T * restrict volatile * ),
    1522         * --?( const restrict T * _Atomic restrict volatile * );
    1523 
    1524 forall( type T ) restrict volatile T * --?( restrict volatile T * restrict volatile * ),
    1525         * --?( restrict volatile T * _Atomic restrict volatile * );
    1526 
    1527 forall( type T ) _Atomic const volatile T * --?( _Atomic const volatile T * restrict volatile * ),
    1528         * --?( _Atomic const volatile T * _Atomic restrict volatile * );
    1529 
    1530 forall( type T ) _Atomic const restrict T * --?( _Atomic const restrict T * restrict volatile * ),
    1531         * --?( _Atomic const restrict T * _Atomic restrict volatile * );
    1532 
    1533 forall( type T ) _Atomic restrict volatile T * --?( _Atomic restrict volatile T * restrict volatile * ),
    1534         * --?( _Atomic restrict volatile T * _Atomic restrict volatile * );
    1535 
    1536 forall( type T ) const restrict volatile T * --?( const restrict volatile T * restrict volatile * ),
    1537         * --?( const restrict volatile T * _Atomic restrict volatile * );
    1538 
    1539 forall( type T ) _Atomic const restrict volatile T * --?( _Atomic const restrict volatile T * restrict volatile * ),
    1540         * --?( _Atomic const restrict volatile T * _Atomic restrict volatile * );
    1541 \end{lstlisting}
    1542 For every extended integer type \lstinline$X$ there exist
    1543 % Don't use predefined: keep this out of prelude.cf.
    1544 \begin{lstlisting}
    1545 X       ++?( volatile X * ),
    1546         ++?( _Atomic volatile X * ),
    1547         --?( volatile X * ),
    1548         --?( _Atomic volatile X * );
    1549 \end{lstlisting}
    1550 For every complete enumerated type \lstinline$E$ there exist
    1551 % Don't use predefined: keep this out of prelude.cf.
    1552 \begin{lstlisting}
    1553 E ++?( volatile E * ),
    1554         ++?( _Atomic volatile E * ),
    1555         ?--( volatile E * ),
    1556         ?--( _Atomic volatile E * );
    1557 \end{lstlisting}
    1558 
    1559 \semantics
    1560 The interpretations of prefix increment and decrement expressions are
    1561 determined in the same way as the interpretations of postfix increment and
    1562 decrement expressions.
    1563 
    1564 
    1565 \subsubsection{Address and indirection operators}
    1566 
    1567 \begin{lstlisting}
    1568 forall( type T ) lvalue T *?( T * );
    1569 forall( type T ) _Atomic lvalue T *?( _Atomic T * );
    1570 forall( type T ) const lvalue T *?( const T * );
    1571 forall( type T ) volatile lvalue T *?( volatile T * );
    1572 forall( type T ) restrict lvalue T *?( restrict T * );
    1573 forall( type T ) _Atomic const lvalue T *?( _Atomic const T * );
    1574 forall( type T ) _Atomic volatile lvalue T *?( _Atomic volatile T * );
    1575 forall( type T ) _Atomic restrict lvalue T *?( _Atomic restrict T * );
    1576 forall( type T ) const volatile lvalue T *?( const volatile T * );
    1577 forall( type T ) const restrict lvalue T *?( const restrict T * );
    1578 forall( type T ) restrict volatile lvalue T *?( restrict volatile T * );
    1579 forall( type T ) _Atomic const volatile lvalue T *?( _Atomic const volatile T * );
    1580 forall( type T ) _Atomic const restrict lvalue T *?( _Atomic const restrict T * );
    1581 forall( type T ) _Atomic restrict volatile lvalue T *?( _Atomic restrict volatile T * );
    1582 forall( type T ) const restrict volatile lvalue T *?( const restrict volatile T * );
    1583 forall( type T ) _Atomic const restrict volatile lvalue T *?( _Atomic const restrict volatile T * );
    1584 
    1585 forall( ftype FT ) FT *?( FT * );
    1586 \end{lstlisting}
    1587 
    1588 \constraints
    1589 The operand of the unary ``\lstinline$&$'' operator shall have exactly one
    1590 \Index{interpretation}\index{ambiguous interpretation}, which shall be unambiguous.
    1591 
    1592 \semantics
    1593 The ``\lstinline$&$'' expression has one interpretation which is of type \lstinline$T *$, where
    1594 \lstinline$T$ is the type of the operand.
    1595 
    1596 The interpretations of an indirection expression are the interpretations of the corresponding
    1597 function call.
    1598 
    1599 
    1600 \subsubsection{Unary arithmetic operators}
    1601 
    1602 \begin{lstlisting}
    1603 int
    1604         +?( int ),
    1605         -?( int ),
    1606         ~?( int );
    1607 unsigned int
    1608         +?( unsigned int ),
    1609         -?( unsigned int ),
    1610          ~?( unsigned int );
    1611 long int
    1612         +?( long int ),
    1613         -?( long int ),
    1614         ~?( long int );
    1615 long unsigned int
    1616         +?( long unsigned int ),
    1617         -?( long unsigned int ),
    1618         ~?( long unsigned int );
    1619 long long int
    1620         +?( long long int ),
    1621         -?( long long int ),
    1622         ~?( long long int );
    1623 long long unsigned int
    1624         +?( long long unsigned int ),
    1625         -?( long long unsigned int ),
    1626         ~?( long long unsigned int );
    1627 float
    1628         +?( float ),
    1629         -?( float );
    1630 double
    1631         +?( double ),
    1632         -?( double );
    1633 long double
    1634         +?( long double ),
    1635         -?( long double );
    1636 _Complex float
    1637         +?( _Complex float ),
    1638         -?( _Complex float );
    1639 _Complex double
    1640         +?( _Complex double ),
    1641         -?( _Complex double );
    1642 _Complex long double
    1643         +?( _Complex long double ),
    1644         -?( _Complex long double );
    1645 
    1646 int !?( int ),
    1647         !?( unsigned int ),
    1648         !?( long ),
    1649         !?( long unsigned int ),
    1650         !?( long long int ),
    1651         !?( long long unsigned int ),
    1652         !?( float ),
    1653         !?( double ),
    1654         !?( long double ),
    1655         !?( _Complex float ),
    1656         !?( _Complex double ),
    1657         !?( _Complex long double );
    1658 
    1659 forall( dtype DT ) int !?( const restrict volatile DT * );
    1660 forall( dtype DT ) int !?( _Atomic const restrict volatile DT * );
    1661 forall( ftype FT ) int !?( FT * );
    1662 \end{lstlisting}
    1663 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the
    1664 rank of \lstinline$int$ there exist
    1665 % Don't use predefined: keep this out of prelude.cf.
    1666 \begin{lstlisting}
    1667 X +?( X ), -?( X ), ~?( X );
    1668 int !?( X );
    1669 \end{lstlisting}
    1670 
    1671 \semantics
    1672 The interpretations of a unary arithmetic expression are the interpretations of the corresponding
    1673 function call.
    1674 
    1675 \examples
    1676 \begin{lstlisting}
    1677 long int li;
    1678 void eat_double( double );@\use{eat_double}@
    1679 
    1680 eat_double(-li ); // @\rewrite@ eat_double( -?( li ) );
    1681 \end{lstlisting}
    1682 The valid interpretations of ``\lstinline$-li$'' (assuming no extended integer types exist) are
    1683 \begin{center}
    1684 \begin{tabular}{llc}
    1685 interpretation & result type & expression conversion cost \\
    1686 \hline
    1687 \lstinline$-?( (int)li )$                                       & \lstinline$int$                                       & (unsafe) \\
    1688 \lstinline$-?( (unsigned)li)$                           & \lstinline$unsigned int$                      & (unsafe) \\
    1689 \lstinline$-?( (long)li)$                                       & \lstinline$long$                                      & 0 \\
    1690 \lstinline$-?( (long unsigned int)li)$          & \lstinline$long unsigned int$         & 1 \\
    1691 \lstinline$-?( (long long int)li)$                      & \lstinline$long long int$                     & 2 \\
    1692 \lstinline$-?( (long long unsigned int)li)$     & \lstinline$long long unsigned int$& 3 \\
    1693 \lstinline$-?( (float)li)$                                      & \lstinline$float$                                     & 4 \\
    1694 \lstinline$-?( (double)li)$                                     & \lstinline$double$                            & 5 \\
    1695 \lstinline$-?( (long double)li)$                        & \lstinline$long double$                       & 6 \\
    1696 \lstinline$-?( (_Complex float)li)$                     & \lstinline$float$                                     & (unsafe) \\
    1697 \lstinline$-?( (_Complex double)li)$            & \lstinline$double$                            & (unsafe) \\
    1698 \lstinline$-?( (_Complex long double)li)$       & \lstinline$long double$                       & (unsafe) \\
    1699 \end{tabular}
    1700 \end{center}
    1701 The valid interpretations of the \lstinline$eat_double$ call, with the cost of the argument
    1702 conversion and the cost of the entire expression, are
    1703 \begin{center}
    1704 \begin{tabular}{lcc}
    1705 interpretation & argument cost & expression cost \\
    1706 \hline
    1707 \lstinline$eat_double( (double)-?( (int)li) )$                                  & 7                     & (unsafe) \\
    1708 \lstinline$eat_double( (double)-?( (unsigned)li) )$                             & 6                     & (unsafe) \\
    1709 \lstinline$eat_double( (double)-?(li) )$                                                & 5                     & \(0+5=5\) \\
    1710 \lstinline$eat_double( (double)-?( (long unsigned int)li) )$    & 4                     & \(1+4=5\) \\
    1711 \lstinline$eat_double( (double)-?( (long long int)li) )$                & 3                     & \(2+3=5\) \\
    1712 \lstinline$eat_double( (double)-?( (long long unsigned int)li) )$& 2            & \(3+2=5\) \\
    1713 \lstinline$eat_double( (double)-?( (float)li) )$                                & 1                     & \(4+1=5\) \\
    1714 \lstinline$eat_double( (double)-?( (double)li) )$                               & 0                     & \(5+0=5\) \\
    1715 \lstinline$eat_double( (double)-?( (long double)li) )$                  & (unsafe)      & (unsafe) \\
    1716 \lstinline$eat_double( (double)-?( (_Complex float)li) )$               & (unsafe)      & (unsafe) \\
    1717 \lstinline$eat_double( (double)-?( (_Complex double)li) )$              & (unsafe)      & (unsafe) \\
    1718 \lstinline$eat_double( (double)-?( (_Complex long double)li) )$ & (unsafe)      & (unsafe) \\
    1719 \end{tabular}
    1720 \end{center}
    1721 Each has result type \lstinline$void$, so the best must be selected. The interpretations involving
    1722 unsafe conversions are discarded. The remainder have equal expression conversion costs, so the
    1723 ``highest argument conversion cost'' rule is invoked, and the chosen interpretation is
    1724 \lstinline$eat_double( (double)-?(li) )$.
    1725 
    1726 
    1727 \subsubsection{The \lstinline$sizeof$ and \lstinline$_Alignof$ operators}
    1728 
    1729 \constraints
    1730 The operand of \lstinline$sizeof$ or \lstinline$_Alignof$ shall not be \lstinline$type$,
    1731 \lstinline$dtype$, or \lstinline$ftype$.
    1732 
    1733 When the \lstinline$sizeof$\use{sizeof} operator is applied to an expression, the expression shall
    1734 have exactly one \Index{interpretation}\index{ambiguous interpretation}, which shall
    1735 be unambiguous. \semantics A \lstinline$sizeof$ or \lstinline$_Alignof$ expression has one
    1736 interpretation, of type \lstinline$size_t$.
    1737 
    1738 When \lstinline$sizeof$ is applied to an identifier declared by a \nonterm{type-declaration} or a
    1739 \nonterm{type-parameter}, it yields the size in bytes of the type that implements the operand. When
    1740 the operand is an opaque type or an inferred type parameter\index{inferred parameter}, the
    1741 expression is not a constant expression.
    1742 
    1743 When \lstinline$_Alignof$ is applied to an identifier declared by a \nonterm{type-declaration} or a
    1744 \nonterm{type-parameter}, it yields the alignment requirement of the type that implements the
    1745 operand. When the operand is an opaque type or an inferred type parameter\index{inferred
    1746 parameter}, the expression is not a constant expression.
    1747 \begin{rationale}
    1748 \begin{lstlisting}
    1749 type Pair = struct { int first, second; };
    1750 size_t p_size = sizeof(Pair);           // constant expression
    1751 
    1752 extern type Rational;@\use{Rational}@
    1753 size_t c_size = sizeof(Rational);       // non-constant expression
    1754 
    1755 forall(type T) T f(T p1, T p2) {
    1756         size_t t_size = sizeof(T);              // non-constant expression
    1757         ...
    1758 }
    1759 \end{lstlisting}
    1760 ``\lstinline$sizeof Rational$'', although not statically known, is fixed. Within \lstinline$f()$,
    1761 ``\lstinline$sizeof(T)$'' is fixed for each call of \lstinline$f()$, but may vary from call to call.
    1762 \end{rationale}
    1763 
    1764 
    1765 \subsection{Cast operators}
    1766 
    1767 \begin{syntax}
    1768 \lhs{cast-expression}
    1769 \rhs \nonterm{unary-expression}
    1770 \rhs \lstinline$($ \nonterm{type-name} \lstinline$)$ \nonterm{cast-expression}
    1771 \end{syntax}
    1772 
    1773 \constraints
    1774 The \nonterm{type-name} in a \nonterm{cast-expression} shall not be \lstinline$type$,
    1775 \lstinline$dtype$, or \lstinline$ftype$.
    1776 
    1777 \semantics
    1778 
    1779 In a \Index{cast expression} ``\lstinline$($\nonterm{type-name}\lstinline$)e$'', if
    1780 \nonterm{type-name} is the type of an interpretation of \lstinline$e$, then that interpretation is
    1781 the only interpretation of the cast expression; otherwise, \lstinline$e$ shall have some
    1782 interpretation that can be converted to \nonterm{type-name}, and the interpretation of the cast
    1783 expression is the cast of the interpretation that can be converted at the lowest cost. The cast
    1784 expression's interpretation is ambiguous\index{ambiguous interpretation} if more than one
    1785 interpretation can be converted at the lowest cost or if the selected interpretation is ambiguous.
    1786 
    1787 \begin{rationale}
    1788 Casts can be used to eliminate ambiguity in expressions by selecting interpretations of
    1789 subexpressions, and to specialize polymorphic functions and values.
    1790 \end{rationale}
    1791 
    1792 
    1793 \subsection{Multiplicative operators}
    1794 
    1795 \begin{syntax}
    1796 \lhs{multiplicative-expression}
    1797 \rhs \nonterm{cast-expression}
    1798 \rhs \nonterm{multiplicative-expression} \lstinline$*$ \nonterm{cast-expression}
    1799 \rhs \nonterm{multiplicative-expression} \lstinline$/$ \nonterm{cast-expression}
    1800 \rhs \nonterm{multiplicative-expression} \lstinline$%$ \nonterm{cast-expression}
    1801 \end{syntax}
    1802 
    1803 \rewriterules
    1804 \begin{lstlisting}
    1805 a * b @\rewrite@ ?*?( a, b )@\use{?*?}@
    1806 a / b @\rewrite@ ?/?( a, b )@\use{?/?}@
    1807 a % b @\rewrite@ ?%?( a, b )@\use{?%?}@
    1808 \end{lstlisting}
    1809 
    1810 \begin{lstlisting}
    1811 int?*?( int, int ),
    1812         ?/?( int, int ),
    1813         ?%?( int, int );
    1814 unsigned int?*?( unsigned int, unsigned int ),
    1815         ?/?( unsigned int, unsigned int ),
    1816         ?%?( unsigned int, unsigned int );
    1817 long int?*?( long int, long int ),
    1818         ?/?( long, long ),
    1819         ?%?( long, long );
    1820 long unsigned int?*?( long unsigned int, long unsigned int ),
    1821         ?/?( long unsigned int, long unsigned int ),
    1822         ?%?( long unsigned int, long unsigned int );
    1823 long long int?*?( long long int, long long int ),
    1824         ?/?( long long int, long long int ),
    1825         ?%?( long long int, long long int );
    1826 long long unsigned int ?*?( long long unsigned int, long long unsigned int ),
    1827         ?/?( long long unsigned int, long long unsigned int ),
    1828         ?%?( long long unsigned int, long long unsigned int );
    1829 float?*?( float, float ),
    1830         ?/?( float, float );
    1831 double?*?( double, double ),
    1832         ?/?( double, double );
    1833 long double?*?( long double, long double ),
    1834         ?/?( long double, long double );
    1835 _Complex float?*?( float, _Complex float ),
    1836         ?/?( float, _Complex float ),
    1837         ?*?( _Complex float, float ),
    1838         ?/?( _Complex float, float ),
    1839         ?*?( _Complex float, _Complex float ),
    1840         ?/?( _Complex float, _Complex float );
    1841 _Complex double?*?( double, _Complex double ),
    1842         ?/?( double, _Complex double ),
    1843         ?*?( _Complex double, double ),
    1844         ?/?( _Complex double, double ),
    1845         ?*?( _Complex double, _Complex double ),
    1846         ?/?( _Complex double, _Complex double );
    1847 _Complex long double?*?( long double, _Complex long double ),
    1848         ?/?( long double, _Complex long double ),
    1849         ?*?( _Complex long double, long double ),
    1850         ?/?( _Complex long double, long double ),
    1851         ?*?( _Complex long double, _Complex long double ),
    1852         ?/?( _Complex long double, _Complex long double );
    1853 \end{lstlisting}
    1854 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the
    1855 rank of \lstinline$int$ there exist
    1856 % Don't use predefined: keep this out of prelude.cf.
    1857 \begin{lstlisting}
    1858 X ?*?( X ), ?/?( X ), ?%?( X );
    1859 \end{lstlisting}
    1860 
    1861 \begin{rationale}
    1862 {\c11} does not include conversions from the \Index{real type}s to \Index{complex type}s in the
    1863 \Index{usual arithmetic conversion}s.  Instead it specifies conversion of the result of binary
    1864 operations on arguments from mixed type domains. \CFA's predefined operators match that pattern.
    1865 \end{rationale}
    1866 
    1867 \semantics
    1868 The interpretations of multiplicative expressions are the interpretations of the corresponding
    1869 function call.
    1870 
    1871 \examples
    1872 \begin{lstlisting}
    1873 int i;
    1874 long li;
    1875 void eat_double( double );@\use{eat_double}@
    1876 eat_double( li % i );
    1877 \end{lstlisting}
    1878 ``\lstinline$li % i$'' is rewritten as ``\lstinline$?%?(li, i )$''. The valid interpretations
    1879 of \lstinline$?%?(li, i )$, the cost\index{conversion cost} of converting their arguments, and
    1880 the cost of converting the result to \lstinline$double$ (assuming no extended integer types are
    1881 present ) are
    1882 \begin{center}
    1883 \begin{tabular}{lcc}
    1884 interpretation & argument cost & result cost \\
    1885 \hline
    1886 \lstinline$ ?%?( (int)li, i )$                                                                          & (unsafe)      & 6     \\
    1887 \lstinline$ ?%?( (unsigned)li,(unsigned)i )$                                            & (unsafe)      & 5     \\
    1888 \lstinline$ ?%?(li,(long)i )$                                                                           & 1                     & 4     \\
    1889 \lstinline$ ?%?( (long unsigned)li,(long unsigned)i )$                          & 3                     & 3     \\
    1890 \lstinline$ ?%?( (long long)li,(long long)i )$                                          & 5                     & 2     \\
    1891 \lstinline$ ?%?( (long long unsigned)li, (long long unsigned)i )$       & 7                     & 1     \\
    1892 \end{tabular}
    1893 \end{center}
    1894 The best interpretation of \lstinline$eat_double( li, i )$ is
    1895 \lstinline$eat_double( (double)?%?(li, (long)i ))$, which has no unsafe conversions and the
    1896 lowest total cost.
    1897 
    1898 \begin{rationale}
    1899 {\c11} defines most arithmetic operations to apply an \Index{integer promotion} to any argument that
    1900 belongs to a type that has an \Index{integer conversion rank} less than that of \lstinline$int$.If
    1901 \lstinline$s$ is a \lstinline$short int$, ``\lstinline$s *s$'' does not have type \lstinline$short int$;
    1902 it is treated as ``\lstinline$( (int)s ) * ( (int)s )$'', and has type \lstinline$int$. \CFA matches
    1903 that pattern; it does not predefine ``\lstinline$short ?*?( short, short )$''.
    1904 
    1905 These ``missing'' operators limit polymorphism. Consider
    1906 \begin{lstlisting}
    1907 forall( type T | T ?*?( T, T ) ) T square( T );
    1908 short s;
    1909 square( s );
    1910 \end{lstlisting}
    1911 Since \CFA does not define a multiplication operator for \lstinline$short int$,
    1912 \lstinline$square( s )$ is treated as \lstinline$square( (int)s )$, and the result has type
    1913 \lstinline$int$. This is mildly surprising, but it follows the {\c11} operator pattern.
    1914 
    1915 A more troubling example is
    1916 \begin{lstlisting}
    1917 forall( type T | ?*?( T, T ) ) T product( T[], int n );
    1918 short sa[5];
    1919 product( sa, 5);
    1920 \end{lstlisting}
    1921 This has no valid interpretations, because \CFA has no conversion from ``array of
    1922 \lstinline$short int$'' to ``array of \lstinline$int$''. The alternatives in such situations
    1923 include
    1924 \begin{itemize}
    1925 \item
    1926 Defining monomorphic overloadings of \lstinline$product$ for \lstinline$short$ and the other
    1927 ``small'' types.
    1928 \item
    1929 Defining ``\lstinline$short ?*?( short, short )$'' within the scope containing the call to
    1930 \lstinline$product$.
    1931 \item
    1932 Defining \lstinline$product$ to take as an argument a conversion function from the ``small'' type to
    1933 the operator's argument type.
    1934 \end{itemize}
    1935 \end{rationale}
    1936 
    1937 
    1938 \subsection{Additive operators}
    1939 
    1940 \begin{syntax}
    1941 \lhs{additive-expression}
    1942 \rhs \nonterm{multiplicative-expression}
    1943 \rhs \nonterm{additive-expression} \lstinline$+$ \nonterm{multiplicative-expression}
    1944 \rhs \nonterm{additive-expression} \lstinline$-$ \nonterm{multiplicative-expression}
    1945 \end{syntax}
    1946 
    1947 \rewriterules
    1948 \begin{lstlisting}
    1949 a + b @\rewrite@ ?+?( a, b )@\use{?+?}@
    1950 a - b @\rewrite@ ?-?( a, b )@\use{?-?}@
    1951 \end{lstlisting}
    1952 
    1953 \begin{lstlisting}
    1954 int?+?( int, int ),
    1955         ?-?( int, int );
    1956 unsigned int?+?( unsigned int, unsigned int ),
    1957         ?-?( unsigned int, unsigned int );
    1958 long int?+?( long int, long int ),
    1959         ?-?( long int, long int );
    1960 long unsigned int?+?( long unsigned int, long unsigned int ),
    1961         ?-?( long unsigned int, long unsigned int );
    1962 long long int?+?( long long int, long long int ),
    1963         ?-?( long long int, long long int );
    1964 long long unsigned int ?+?( long long unsigned int, long long unsigned int ),
    1965         ?-?( long long unsigned int, long long unsigned int );
    1966 float?+?( float, float ),
    1967         ?-?( float, float );
    1968 double?+?( double, double ),
    1969         ?-?( double, double );
    1970 long double?+?( long double, long double ),
    1971         ?-?( long double, long double );
    1972 _Complex float?+?( _Complex float, float ),
    1973         ?-?( _Complex float, float ),
    1974         ?+?( float, _Complex float ),
    1975         ?-?( float, _Complex float ),
    1976         ?+?( _Complex float, _Complex float ),
    1977         ?-?( _Complex float, _Complex float );
    1978 _Complex double?+?( _Complex double, double ),
    1979         ?-?( _Complex double, double ),
    1980         ?+?( double, _Complex double ),
    1981         ?-?( double, _Complex double ),
    1982         ?+?( _Complex double, _Complex double ),
    1983         ?-?( _Complex double, _Complex double );
    1984 _Complex long double?+?( _Complex long double, long double ),
    1985         ?-?( _Complex long double, long double ),
    1986         ?+?( long double, _Complex long double ),
    1987         ?-?( long double, _Complex long double ),
    1988         ?+?( _Complex long double, _Complex long double ),
    1989         ?-?( _Complex long double, _Complex long double );
    1990 
    1991 forall( type T ) T
    1992         * ?+?( T *, ptrdiff_t ),
    1993         * ?+?( ptrdiff_t, T * ),
    1994         * ?-?( T *, ptrdiff_t );
    1995 
    1996 forall( type T ) _Atomic T
    1997         * ?+?( _Atomic T *, ptrdiff_t ),
    1998         * ?+?( ptrdiff_t, _Atomic T * ),
    1999         * ?-?( _Atomic T *, ptrdiff_t );
    2000 
    2001 forall( type T ) const T
    2002         * ?+?( const T *, ptrdiff_t ),
    2003         * ?+?( ptrdiff_t, const T * ),
    2004         * ?-?( const T *, ptrdiff_t );
    2005 
    2006 forall( type T ) restrict T
    2007         * ?+?( restrict T *, ptrdiff_t ),
    2008         * ?+?( ptrdiff_t, restrict T * ),
    2009         * ?-?( restrict T *, ptrdiff_t );
    2010 
    2011 forall( type T ) volatile T
    2012         * ?+?( volatile T *, ptrdiff_t ),
    2013         * ?+?( ptrdiff_t, volatile T * ),
    2014         * ?-?( volatile T *, ptrdiff_t );
    2015 
    2016 forall( type T ) _Atomic const T
    2017         * ?+?( _Atomic const T *, ptrdiff_t ),
    2018         * ?+?( ptrdiff_t, _Atomic const T * ),
    2019         * ?-?( _Atomic const T *, ptrdiff_t );
    2020 
    2021 forall( type T ) _Atomic restrict T
    2022         * ?+?( _Atomic restrict T *, ptrdiff_t ),
    2023         * ?+?( ptrdiff_t, _Atomic restrict T * ),
    2024         * ?-?( _Atomic restrict T *, ptrdiff_t );
    2025 
    2026 forall( type T ) _Atomic volatile T
    2027         * ?+?( _Atomic volatile T *, ptrdiff_t ),
    2028         * ?+?( ptrdiff_t, _Atomic volatile T * ),
    2029         * ?-?( _Atomic volatile T *, ptrdiff_t );
    2030 
    2031 forall( type T ) const restrict T
    2032         * ?+?( const restrict T *, ptrdiff_t ),
    2033         * ?+?( ptrdiff_t, const restrict T * ),
    2034         * ?-?( const restrict T *, ptrdiff_t );
    2035 
    2036 forall( type T ) const volatile T
    2037         * ?+?( const volatile T *, ptrdiff_t ),
    2038         * ?+?( ptrdiff_t, const volatile T * ),
    2039         * ?-?( const volatile T *, ptrdiff_t );
    2040 
    2041 forall( type T ) restrict volatile T
    2042         * ?+?( restrict volatile T *, ptrdiff_t ),
    2043         * ?+?( ptrdiff_t, restrict volatile T * ),
    2044         * ?-?( restrict volatile T *, ptrdiff_t );
    2045 
    2046 forall( type T ) _Atomic const restrict T
    2047         * ?+?( _Atomic const restrict T *, ptrdiff_t ),
    2048         * ?+?( ptrdiff_t, _Atomic const restrict T * ),
    2049         * ?-?( _Atomic const restrict T *, ptrdiff_t );
    2050 
    2051 forall( type T ) ptrdiff_t
    2052         * ?-?( const restrict volatile T *, const restrict volatile T * ),
    2053         * ?-?( _Atomic const restrict volatile T *, _Atomic const restrict volatile T * );
    2054 \end{lstlisting}
    2055 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the
    2056 rank of \lstinline$int$ there exist
    2057 % Don't use predefined: keep this out of prelude.cf.
    2058 \begin{lstlisting}
    2059 X ?+?( X ), ?-?( X );
    2060 \end{lstlisting}
    2061 
    2062 \semantics
    2063 The interpretations of additive expressions are the interpretations of the corresponding function
    2064 calls.
    2065 
    2066 \begin{rationale}
    2067 \lstinline$ptrdiff_t$ is an implementation-defined identifier defined in \lstinline$<stddef.h>$ that
    2068 is synonymous with a signed integral type that is large enough to hold the difference between two
    2069 pointers. It seems reasonable to use it for pointer addition as well. (This is technically a
    2070 difference between \CFA and C, which only specifies that pointer addition uses an \emph{integral}
    2071 argument.) Hence it is also used for subscripting, which is defined in terms of pointer addition.
    2072 The {\c11} standard uses \lstinline$size_t$ in several cases where a library function takes an
    2073 argument that is used as a subscript, but \lstinline$size_t$ is unsuitable here because it is an
    2074 unsigned type.
    2075 \end{rationale}
    2076 
    2077 
    2078 \subsection{Bitwise shift operators}
    2079 
    2080 \begin{syntax}
    2081 \lhs{shift-expression}
    2082 \rhs \nonterm{additive-expression}
    2083 \rhs \nonterm{shift-expression} \lstinline$<<$ \nonterm{additive-expression}
    2084 \rhs \nonterm{shift-expression} \lstinline$>>$ \nonterm{additive-expression}
    2085 \end{syntax}
    2086 
    2087 \rewriterules \use{?>>?}%use{?<<?}
    2088 \begin{lstlisting}
    2089 a << b @\rewrite@ ?<<?( a, b )
    2090 a >> b @\rewrite@ ?>>?( a, b )
    2091 \end{lstlisting}
    2092 
    2093 \begin{lstlisting}
    2094 int ?<<?( int, int ),
    2095          ?>>?( int, int );
    2096 unsigned int ?<<?( unsigned int, int ),
    2097          ?>>?( unsigned int, int );
    2098 long int ?<<?( long int, int ),
    2099          ?>>?( long int, int );
    2100 long unsigned int ?<<?( long unsigned int, int ),
    2101          ?>>?( long unsigned int, int );
    2102 long long int ?<<?( long long int, int ),
    2103          ?>>?( long long int, int );
    2104 long long unsigned int ?<<?( long long unsigned int, int ),
    2105          ?>>?( long long unsigned int, int);
    2106 \end{lstlisting}
    2107 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the
    2108 rank of \lstinline$int$ there exist
    2109 % Don't use predefined: keep this out of prelude.cf.
    2110 \begin{lstlisting}
    2111 X ?<<?( X, int ), ?>>?( X, int );
    2112 \end{lstlisting}
    2113 
    2114 \begin{rationale}
    2115 The bitwise shift operators break the usual pattern: they do not convert both operands to a common
    2116 type. The right operand only undergoes \Index{integer promotion}.
    2117 \end{rationale}
    2118 
    2119 \semantics
    2120 The interpretations of a bitwise shift expression are the interpretations of the corresponding
    2121 function calls.
    2122 
    2123 
    2124 \subsection{Relational operators}
    2125 
    2126 \begin{syntax}
    2127 \lhs{relational-expression}
    2128 \rhs \nonterm{shift-expression}
    2129 \rhs \nonterm{relational-expression} \lstinline$< $ \nonterm{shift-expression}
    2130 \rhs \nonterm{relational-expression} \lstinline$> $ \nonterm{shift-expression}
    2131 \rhs \nonterm{relational-expression} \lstinline$<=$ \nonterm{shift-expression}
    2132 \rhs \nonterm{relational-expression} \lstinline$>=$ \nonterm{shift-expression}
    2133 \end{syntax}
    2134 
    2135 \rewriterules\use{?>?}\use{?>=?}%use{?<?}%use{?<=?}
    2136 \begin{lstlisting}
    2137 a < b @\rewrite@ ?<?( a, b )
    2138 a > b @\rewrite@ ?>?( a, b )
    2139 a <= b @\rewrite@ ?<=?( a, b )
    2140 a >= b @\rewrite@ ?>=?( a, b )
    2141 \end{lstlisting}
    2142 
    2143 \begin{lstlisting}
    2144 int ?<?( int, int ),
    2145         ?<=?( int, int ),
    2146         ?>?( int, int ),
    2147         ?>=?( int, int );
    2148 int ?<?( unsigned int, unsigned int ),
    2149         ?<=?( unsigned int, unsigned int ),
    2150         ?>?( unsigned int, unsigned int ),
    2151         ?>=?( unsigned int, unsigned int );
    2152 int ?<?( long int, long int ),
    2153         ?<=?( long int, long int ),
    2154         ?>?( long int, long int ),
    2155         ?>=?( long int, long int );
    2156 int ?<?( long unsigned int, long unsigned ),
    2157         ?<=?( long unsigned int, long unsigned ),
    2158         ?>?( long unsigned int, long unsigned ),
    2159         ?>=?( long unsigned int, long unsigned );
    2160 int ?<?( long long int, long long int ),
    2161         ?<=?( long long int, long long int ),
    2162         ?>?( long long int, long long int ),
    2163         ?>=?( long long int, long long int );
    2164 int ?<?( long long unsigned int, long long unsigned ),
    2165         ?<=?( long long unsigned int, long long unsigned ),
    2166         ?>?( long long unsigned int, long long unsigned ),
    2167         ?>=?( long long unsigned int, long long unsigned );
    2168 int ?<?( float, float ),
    2169         ?<=?( float, float ),
    2170         ?>?( float, float ),
    2171         ?>=?( float, float );
    2172 int ?<?( double, double ),
    2173         ?<=?( double, double ),
    2174         ?>?( double, double ),
    2175         ?>=?( double, double );
    2176 int ?<?( long double, long double ),
    2177         ?<=?( long double, long double ),
    2178         ?>?( long double, long double ),
    2179         ?>=?( long double, long double );
    2180 
    2181 forall( dtype DT ) int
    2182         ?<?( const restrict volatile DT *, const restrict volatile DT * ),
    2183         ?<?( _Atomic const restrict volatile DT *, _Atomic const restrict volatile DT * ),
    2184         ?<=?( const restrict volatile DT *, const restrict volatile DT * ),
    2185         ?<=?( _Atomic const restrict volatile DT *, _Atomic const restrict volatile DT * ),
    2186         ?>?( const restrict volatile DT *, const restrict volatile DT * ),
    2187         ?>?( _Atomic const restrict volatile DT *, _Atomic const restrict volatile DT * ),
    2188         ?>=?( const restrict volatile DT *, const restrict volatile DT * ),
    2189         ?>=?( _Atomic const restrict volatile DT *, _Atomic const restrict volatile DT * );
    2190 \end{lstlisting}
    2191 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the
    2192 rank of \lstinline$int$ there exist
    2193 % Don't use predefined: keep this out of prelude.cf.
    2194 \begin{lstlisting}
    2195 int ?<?( X, X ),
    2196         ?<=?( X, X ),
    2197         ?<?( X, X ),
    2198         ?>=?( X, X );
    2199 \end{lstlisting}
    2200 
    2201 \semantics
    2202 The interpretations of a relational expression are the interpretations of the corresponding function
    2203 call.
    2204 
    2205 
    2206 \subsection{Equality operators}
    2207 
    2208 \begin{syntax}
    2209 \lhs{equality-expression}
    2210 \rhs \nonterm{relational-expression}
    2211 \rhs \nonterm{equality-expression} \lstinline$==$ \nonterm{relational-expression}
    2212 \rhs \nonterm{equality-expression} \lstinline$!=$ \nonterm{relational-expression}
    2213 \end{syntax}
    2214 
    2215 \rewriterules
    2216 \begin{lstlisting}
    2217 a == b @\rewrite@ ?==?( a, b )@\use{?==?}@
    2218 a != b @\rewrite@ ?!=?( a, b )@\use{?"!=?}@
    2219 \end{lstlisting}
    2220 
    2221 \begin{lstlisting}
    2222 int ?==?( int, int ),
    2223         ?!=?( int, int ),
    2224         ?==?( unsigned int, unsigned int ),
    2225         ?!=?( unsigned int, unsigned int ),
    2226         ?==?( long int, long int ),
    2227         ?!=?( long int, long int ),
    2228         ?==?( long unsigned int, long unsigned int ),
    2229         ?!=?( long unsigned int, long unsigned int ),
    2230         ?==?( long long int, long long int ),
    2231         ?!=?( long long int, long long int ),
    2232         ?==?( long long unsigned int, long long unsigned int ),
    2233         ?!=?( long long unsigned int, long long unsigned int ),
    2234         ?==?( float, float ),
    2235         ?!=?( float, float ),
    2236         ?==?( _Complex float, float ),
    2237         ?!=?( _Complex float, float ),
    2238         ?==?( float, _Complex float ),
    2239         ?!=?( float, _Complex float ),
    2240         ?==?( _Complex float, _Complex float ),
    2241         ?!=?( _Complex float, _Complex float ),
    2242         ?==?( double, double ),
    2243         ?!=?( double, double ),
    2244         ?==?( _Complex double, double ),
    2245         ?!=?( _Complex double, double ),
    2246         ?==?( double, _Complex double ),
    2247         ?!=?( double, _Complex double ),
    2248         ?==?( _Complex double, _Complex double ),
    2249         ?!=?( _Complex double, _Complex double ),
    2250         ?==?( long double, long double ),
    2251         ?!=?( long double, long double ),
    2252         ?==?( _Complex long double, long double ),
    2253         ?!=?( _Complex long double, long double ),
    2254         ?==?( long double, _Complex long double ),
    2255         ?!=?( long double, _Complex long double ),
    2256         ?==?( _Complex long double, _Complex long double ),
    2257         ?!=?( _Complex long double, _Complex long double );
    2258 
    2259 forall( dtype DT ) int
    2260         ?==?( const restrict volatile DT *, const restrict volatile DT * ),
    2261         ?!=?( const restrict volatile DT *, const restrict volatile DT * ),
    2262         ?==?( const restrict volatile DT *, const restrict volatile void * ),
    2263         ?!=?( const restrict volatile DT *, const restrict volatile void * ),
    2264         ?==?( const restrict volatile void *, const restrict volatile DT * ),
    2265         ?!=?( const restrict volatile void *, const restrict volatile DT * ),
    2266         ?==?( const restrict volatile DT *, forall( dtype DT2) const DT2 * ),
    2267         ?!=?( const restrict volatile DT *, forall( dtype DT2) const DT2 * ),
    2268         ?==?( forall( dtype DT2) const DT2*, const restrict volatile DT * ),
    2269         ?!=?( forall( dtype DT2) const DT2*, const restrict volatile DT * ),
    2270         ?==?( forall( dtype DT2) const DT2*, forall( dtype DT3) const DT3 * ),
    2271         ?!=?( forall( dtype DT2) const DT2*, forall( dtype DT3) const DT3 * ),
    2272 
    2273         ?==?( _Atomic const restrict volatile DT *, _Atomic const restrict volatile DT * ),
    2274         ?!=?( _Atomic const restrict volatile DT *, _Atomic const restrict volatile DT * ),
    2275         ?==?( _Atomic const restrict volatile DT *, const restrict volatile void * ),
    2276         ?!=?( _Atomic const restrict volatile DT *, const restrict volatile void * ),
    2277         ?==?( const restrict volatile void *, _Atomic const restrict volatile DT * ),
    2278         ?!=?( const restrict volatile void *, _Atomic const restrict volatile DT * ),
    2279         ?==?( _Atomic const restrict volatile DT *, forall( dtype DT2) const DT2 * ),
    2280         ?!=?( _Atomic const restrict volatile DT *, forall( dtype DT2) const DT2 * ),
    2281         ?==?( forall( dtype DT2) const DT2*, _Atomic const restrict volatile DT * ),
    2282         ?!=?( forall( dtype DT2) const DT2*, _Atomic const restrict volatile DT * );
    2283 
    2284 forall( ftype FT ) int
    2285         ?==?( FT *, FT * ),
    2286         ?!=?( FT *, FT * ),
    2287         ?==?( FT *, forall( ftype FT2) FT2 * ),
    2288         ?!=?( FT *, forall( ftype FT2) FT2 * ),
    2289         ?==?( forall( ftype FT2) FT2*, FT * ),
    2290         ?!=?( forall( ftype FT2) FT2*, FT * ),
    2291         ?==?( forall( ftype FT2) FT2*, forall( ftype FT3) FT3 * ),
    2292         ?!=?( forall( ftype FT2) FT2*, forall( ftype FT3) FT3 * );
    2293 \end{lstlisting}
    2294 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the
    2295 rank of \lstinline$int$ there exist
    2296 % Don't use predefined: keep this out of prelude.cf.
    2297 \begin{lstlisting}
    2298 int ?==?( X, X ),
    2299         ?!=?( X, X );
    2300 \end{lstlisting}
    2301 
    2302 \begin{rationale}
    2303 The polymorphic equality operations come in three styles: comparisons between pointers of compatible
    2304 types, between pointers to \lstinline$void$ and pointers to object types or incomplete types, and
    2305 between the \Index{null pointer} constant and pointers to any type. In the last case, a special
    2306 constraint rule for null pointer constant operands has been replaced by a consequence of the \CFA
    2307 type system.
    2308 \end{rationale}
    2309 
    2310 \semantics
    2311 The interpretations of an equality expression are the interpretations of the corresponding function
    2312 call.
    2313 
    2314 \begin{sloppypar}
    2315 The result of an equality comparison between two pointers to predefined functions or predefined
    2316 values is implementation-defined.
    2317 \end{sloppypar}
    2318 \begin{rationale}
    2319 The implementation-defined status of equality comparisons allows implementations to use one library
    2320 routine to implement many predefined functions. These optimization are particularly important when
    2321 the predefined functions are polymorphic, as is the case for most pointer operations
    2322 \end{rationale}
    2323 
    2324 
    2325 \subsection{Bitwise AND operator}
    2326 
    2327 \begin{syntax}
    2328 \lhs{AND-expression}
    2329 \rhs \nonterm{equality-expression}
    2330 \rhs \nonterm{AND-expression} \lstinline$&$ \nonterm{equality-expression}
    2331 \end{syntax}
    2332 
    2333 \rewriterules
    2334 \begin{lstlisting}
    2335 a & b @\rewrite@ ?&?( a, b )@\use{?&?}@
    2336 \end{lstlisting}
    2337 
    2338 \begin{lstlisting}
    2339 int ?&?( int, int );
    2340 unsigned int ?&?( unsigned int, unsigned int );
    2341 long int ?&?( long int, long int );
    2342 long unsigned int ?&?( long unsigned int, long unsigned int );
    2343 long long int ?&?( long long int, long long int );
    2344 long long unsigned int ?&?( long long unsigned int, long long unsigned int );
    2345 \end{lstlisting}
    2346 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the
    2347 rank of \lstinline$int$ there exist
    2348 % Don't use predefined: keep this out of prelude.cf.
    2349 \begin{lstlisting}
    2350 int ?&?( X, X );
    2351 \end{lstlisting}
    2352 
    2353 \semantics
    2354 The interpretations of a bitwise AND expression are the interpretations of the corresponding
    2355 function call.
    2356 
    2357 
    2358 \subsection{Bitwise exclusive OR operator}
    2359 
    2360 \begin{syntax}
    2361 \lhs{exclusive-OR-expression}
    2362 \rhs \nonterm{AND-expression}
    2363 \rhs \nonterm{exclusive-OR-expression} \lstinline$^$ \nonterm{AND-expression}
    2364 \end{syntax}
    2365 
    2366 \rewriterules
    2367 \begin{lstlisting}
    2368 a ^ b @\rewrite@ ?^?( a, b )@\use{?^?}@
    2369 \end{lstlisting}
    2370 
    2371 \begin{lstlisting}
    2372 int ?^?( int, int );
    2373 unsigned int ?^?( unsigned int, unsigned int );
    2374 long int ?^?( long int, long int );
    2375 long unsigned int ?^?( long unsigned int, long unsigned int );
    2376 long long int ?^?( long long int, long long int );
    2377 long long unsigned int ?^?( long long unsigned int, long long unsigned int );
    2378 \end{lstlisting}
    2379 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the
    2380 rank of \lstinline$int$ there exist
    2381 % Don't use predefined: keep this out of prelude.cf.
    2382 \begin{lstlisting}
    2383 int ?^?( X, X );
    2384 \end{lstlisting}
    2385 
    2386 \semantics
    2387 The interpretations of a bitwise exclusive OR expression are the interpretations of the
    2388 corresponding function call.
    2389 
    2390 
    2391 \subsection{Bitwise inclusive OR operator}
    2392 
    2393 \begin{syntax}
    2394 \lhs{inclusive-OR-expression}
    2395 \rhs \nonterm{exclusive-OR-expression}
    2396 \rhs \nonterm{inclusive-OR-expression} \lstinline$|$ \nonterm{exclusive-OR-expression}
    2397 \end{syntax}
    2398 
    2399 \rewriterules\use{?"|?}
    2400 \begin{lstlisting}
    2401 a | b @\rewrite@ ?|?( a, b )
    2402 \end{lstlisting}
    2403 
    2404 \begin{lstlisting}
    2405 int ?|?( int, int );
    2406 unsigned int ?|?( unsigned int, unsigned int );
    2407 long int ?|?( long int, long int );
    2408 long unsigned int ?|?( long unsigned int, long unsigned int );
    2409 long long int ?|?( long long int, long long int );
    2410 long long unsigned int ?|?( long long unsigned int, long long unsigned int );
    2411 \end{lstlisting}
    2412 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the
    2413 rank of \lstinline$int$ there exist
    2414 % Don't use predefined: keep this out of prelude.cf.
    2415 \begin{lstlisting}
    2416 int ?|?( X, X );
    2417 \end{lstlisting}
    2418 
    2419 \semantics
    2420 The interpretations of a bitwise inclusive OR expression are the interpretations of the
    2421 corresponding function call.
    2422 
    2423 
    2424 \subsection{Logical AND operator}
    2425 
    2426 \begin{syntax}
    2427 \lhs{logical-AND-expression}
    2428 \rhs \nonterm{inclusive-OR-expression}
    2429 \rhs \nonterm{logical-AND-expression} \lstinline$&&$ \nonterm{inclusive-OR-expression}
    2430 \end{syntax}
    2431 
    2432 \semantics The operands of the expression ``\lstinline$a && b$'' are treated as
    2433 ``\lstinline$(int)((a)!=0)$'' and ``\lstinline$(int)((b)!=0)$'', which shall both be
    2434 unambiguous. The expression has only one interpretation, which is of type \lstinline$int$.
    2435 \begin{rationale}
    2436 When the operands of a logical expression are values of built-in types, and ``\lstinline$!=$'' has
    2437 not been redefined for those types, the compiler can optimize away the function calls.
    2438 
    2439 A common C idiom omits comparisons to \lstinline$0$ in the controlling expressions of loops and
    2440 \lstinline$if$ statements. For instance, the loop below iterates as long as \lstinline$rp$ points
    2441 at a \lstinline$Rational$ value that is non-zero.
    2442 
    2443 \begin{lstlisting}
    2444 extern type Rational;@\use{Rational}@
    2445 extern const Rational 0;@\use{0}@
    2446 extern int ?!=?( Rational, Rational );
    2447 Rational *rp;
    2448 
    2449 while ( rp && *rp ) { ... }
    2450 \end{lstlisting}
    2451 The logical expression calls the \lstinline$Rational$ inequality operator, passing
    2452 it \lstinline$*rp$ and the \lstinline$Rational 0$, and getting a 1 or 0 as a result. In
    2453 contrast, {\CC} would apply a programmer-defined \lstinline$Rational$-to-\lstinline$int$
    2454 conversion to \lstinline$*rp$ in the equivalent situation. The conversion to \lstinline$int$ would
    2455 produce a general integer value, which is unfortunate, and possibly dangerous if the conversion was
    2456 not written with this situation in mind.
    2457 \end{rationale}
    2458 
    2459 
    2460 \subsection{Logical OR operator}
    2461 
    2462 \begin{syntax}
    2463 \lhs{logical-OR-expression}
    2464 \rhs \nonterm{logical-AND-expression}
    2465 \rhs \nonterm{logical-OR-expression} \lstinline$||$ \nonterm{logical-AND-expression}
    2466 \end{syntax}
    2467 
    2468 \semantics
    2469 
    2470 The operands of the expression ``\lstinline$a || b$'' are treated as ``\lstinline$(int)((a)!=0)$''
    2471 and ``\lstinline$(int)((b))!=0)$'', which shall both be unambiguous. The expression has only one
    2472 interpretation, which is of type \lstinline$int$.
    2473 
    2474 
    2475 \subsection{Conditional operator}
    2476 
    2477 \begin{syntax}
    2478 \lhs{conditional-expression}
    2479 \rhs \nonterm{logical-OR-expression}
    2480 \rhs \nonterm{logical-OR-expression} \lstinline$?$ \nonterm{expression}
    2481          \lstinline$:$ \nonterm{conditional-expression}
    2482 \end{syntax}
    2483 
    2484 \semantics
    2485 In the conditional expression\use{?:} ``\lstinline$a?b:c$'', if the second and
    2486 third operands both have an interpretation with \lstinline$void$ type, then the expression has an
    2487 interpretation with type \lstinline$void$, equivalent to
    2488 \begin{lstlisting}
    2489 ( int)(( a)!=0) ? ( void)( b) : ( void)( c)
    2490 \end{lstlisting}
    2491 
    2492 If the second and third operands both have interpretations with non-\lstinline$void$ types, the
    2493 expression is treated as if it were the call ``\lstinline$cond((a)!=0, b, c)$'',
    2494 with \lstinline$cond$ declared as
    2495 \begin{lstlisting}
    2496 forall( type T ) T cond( int, T, T );
    2497  
    2498 forall( dtype D ) void
    2499         * cond( int, D *, void * ),
    2500         * cond( int, void *, D * );
    2501        
    2502 forall( dtype D ) _atomic void
    2503         * cond( int, _Atomic D *, _Atomic void * ),
    2504         * cond( int, _Atomic void *, _Atomic D * );
    2505 
    2506 forall( dtype D ) const void
    2507         * cond( int, const D *, const void * ),
    2508         * cond( int, const void *, const D * );
    2509 
    2510 forall( dtype D ) restrict void
    2511         * cond( int, restrict D *, restrict void * ),
    2512         * cond( int, restrict void *, restrict D * );
    2513 
    2514 forall( dtype D ) volatile void
    2515         * cond( int, volatile D *, volatile void * ),
    2516         * cond( int, volatile void *, volatile D * );
    2517 
    2518 forall( dtype D ) _Atomic const void
    2519         * cond( int, _Atomic const D *, _Atomic const void * ),
    2520         * cond( int, _Atomic const void *, _Atomic const D * );
    2521 
    2522 forall( dtype D ) _Atomic restrict void
    2523         * cond( int, _Atomic restrict D *, _Atomic restrict void * ),
    2524         * cond( int, _Atomic restrict void *, _Atomic restrict D * );
    2525 
    2526 forall( dtype D ) _Atomic volatile void
    2527         * cond( int, _Atomic volatile D *, _Atomic volatile void * ),
    2528         * cond( int, _Atomic volatile void *, _Atomic volatile D * );
    2529 
    2530 forall( dtype D ) const restrict void
    2531         * cond( int, const restrict D *, const restrict void * ),
    2532         * cond( int, const restrict void *, const restrict D * );
    2533 
    2534 forall( dtype D ) const volatile void
    2535         * cond( int, const volatile D *, const volatile void * ),
    2536         * cond( int, const volatile void *, const volatile D * );
    2537 
    2538 forall( dtype D ) restrict volatile void
    2539         * cond( int, restrict volatile D *, restrict volatile void * ),
    2540         * cond( int, restrict volatile void *, restrict volatile D * );
    2541 
    2542 forall( dtype D ) _Atomic const restrict void
    2543         * cond( int, _Atomic const restrict D *, _Atomic const restrict void * ),
    2544         * cond( int, _Atomic const restrict void *, _Atomic const restrict D * );
    2545 
    2546 forall( dtype D ) _Atomic const volatile void
    2547         * cond( int, _Atomic const volatile D *, _Atomic const volatile void * ),
    2548         * cond( int, _Atomic const volatile void *, _Atomic const volatile D * );
    2549 
    2550 forall( dtype D ) _Atomic restrict volatile void
    2551         * cond( int, _Atomic restrict volatile D *,
    2552          _Atomic restrict volatile void * ),
    2553         * cond( int, _Atomic restrict volatile void *,
    2554          _Atomic restrict volatile D * );
    2555 
    2556 forall( dtype D ) const restrict volatile void
    2557         * cond( int, const restrict volatile D *,
    2558          const restrict volatile void * ),
    2559         * cond( int, const restrict volatile void *,
    2560          const restrict volatile D * );
    2561 
    2562 forall( dtype D ) _Atomic const restrict volatile void
    2563         * cond( int, _Atomic const restrict volatile D *,
    2564          _Atomic const restrict volatile void * ),
    2565         * cond( int, _Atomic const restrict volatile void *,
    2566          _Atomic const restrict volatile D * );
    2567 \end{lstlisting}
    2568 
    2569 \begin{rationale}
    2570 The object of the above is to apply the \Index{usual arithmetic conversion}s when the second and
    2571 third operands have arithmetic type, and to combine the qualifiers of the second and third operands
    2572 if they are pointers.
    2573 \end{rationale}
    2574 
    2575 \examples
    2576 \begin{lstlisting}
    2577 #include <stdlib.h>
    2578 int i;
    2579 long l;
    2580 rand() ? i : l;
    2581 \end{lstlisting}
    2582 The best interpretation infers the expression's type to be \lstinline$long$ and applies the safe
    2583 \lstinline$int$-to-\lstinline$long$ conversion to \lstinline$i$.
    2584 
    2585 \begin{lstlisting}
    2586 const int *cip;
    2587 volatile int *vip;
    2588 rand() ? cip : vip;
    2589 \end{lstlisting}
    2590 The expression has type \lstinline$const volatile int *$, with safe conversions applied to the second
    2591 and third operands to add \lstinline$volatile$ and \lstinline$const$ qualifiers, respectively.
    2592 
    2593 \begin{lstlisting}
    2594 rand() ? cip : 0;
    2595 \end{lstlisting}
    2596 The expression has type \lstinline$const int *$, with a specialization conversion applied to
    2597 \lstinline$0$.
    2598 
    2599 
    2600 \subsection{Assignment operators}
    2601 
    2602 \begin{syntax}
    2603 \lhs{assignment-expression}
    2604 \rhs \nonterm{conditional-expression}
    2605 \rhs \nonterm{unary-expression} \nonterm{assignment-operator}
    2606          \nonterm{assignment-expression}
    2607 \lhs{assignment-operator} one of
    2608 \rhs \lstinline$=$\ \ \lstinline$*=$\ \ \lstinline$/=$\ \ \lstinline$%=$\ \ \lstinline$+=$\ \ \lstinline$-=$\ \ 
    2609          \lstinline$<<=$\ \ \lstinline$>>=$\ \ \lstinline$&=$\ \ \lstinline$^=$\ \ \lstinline$|=$
    2610 \end{syntax}
    2611 
    2612 \rewriterules
    2613 Let ``\(\leftarrow\)'' be any of the assignment operators. Then
    2614 \use{?=?}\use{?*=?}\use{?/=?}\use{?%=?}\use{?+=?}\use{?-=?}
    2615 \use{?>>=?}\use{?&=?}\use{?^=?}\use{?"|=?}%use{?<<=?}
    2616 \begin{lstlisting}
    2617 a @$\leftarrow$@ b @\rewrite@ ?@$\leftarrow$@?( &( a ), b )
    2618 \end{lstlisting}
    2619 
    2620 \semantics
    2621 Each interpretation of the left operand of an assignment expression is considered separately. For
    2622 each interpretation that is a bit-field or is declared with the \lstinline$register$ storage class
    2623 specifier, the expression has one valid interpretation, with the type of the left operand. The
    2624 right operand is cast to that type, and the assignment expression is ambiguous if either operand is.
    2625 For the remaining interpretations, the expression is rewritten, and the interpretations of the
    2626 assignment expression are the interpretations of the corresponding function call. Finally, all
    2627 interpretations of the expression produced for the different interpretations of the left operand are
    2628 combined to produce the interpretations of the expression as a whole; where interpretations have
    2629 compatible result types, the best interpretations are selected in the manner described for function
    2630 call expressions.
    2631 
    2632 
    2633 \subsubsection{Simple assignment}
    2634 
    2635 \begin{lstlisting}
    2636 _Bool
    2637         ?=?( volatile _Bool *, _Bool ),
    2638         ?=?( volatile _Bool *, forall( dtype D ) D * ),
    2639         ?=?( volatile _Bool *, forall( ftype F ) F * ),
    2640         ?=?( _Atomic volatile _Bool *, _Bool ),
    2641         ?=?( _Atomic volatile _Bool *, forall( dtype D ) D * ),
    2642         ?=?( _Atomic volatile _Bool *, forall( ftype F ) F * );
    2643 char
    2644         ?=?( volatile char *, char ),
    2645         ?=?( _Atomic volatile char *, char );
    2646 unsigned char
    2647         ?=?( volatile unsigned char *, unsigned char ),
    2648         ?=?( _Atomic volatile unsigned char *, unsigned char );
    2649 signed char
    2650         ?=?( volatile signed char *, signed char ),
    2651         ?=?( _Atomic volatile signed char *, signed char );
    2652 short int
    2653         ?=?( volatile short int *, short int ),
    2654         ?=?( _Atomic volatile short int *, short int );
    2655 unsigned short
    2656         ?=?( volatile unsigned int *, unsigned int ),
    2657         ?=?( _Atomic volatile unsigned int *, unsigned int );
    2658 int
    2659         ?=?( volatile int *, int ),
    2660         ?=?( _Atomic volatile int *, int );
    2661 unsigned int
    2662         ?=?( volatile unsigned int *, unsigned int ),
    2663         ?=?( _Atomic volatile unsigned int *, unsigned int );
    2664 long int
    2665         ?=?( volatile long int *, long int ),
    2666         ?=?( _Atomic volatile long int *, long int );
    2667 unsigned long int
    2668         ?=?( volatile unsigned long int *, unsigned long int ),
    2669         ?=?( _Atomic volatile unsigned long int *, unsigned long int );
    2670 long long int
    2671         ?=?( volatile long long int *, long long int ),
    2672         ?=?( _Atomic volatile long long int *, long long int );
    2673 unsigned long long int
    2674         ?=?( volatile unsigned long long int *, unsigned long long int ),
    2675         ?=?( _Atomic volatile unsigned long long int *, unsigned long long int );
    2676 float
    2677         ?=?( volatile float *, float ),
    2678         ?=?( _Atomic volatile float *, float );
    2679 double
    2680         ?=?( volatile double *, double ),
    2681         ?=?( _Atomic volatile double *, double );
    2682 long double
    2683         ?=?( volatile long double *, long double ),
    2684         ?=?( _Atomic volatile long double *, long double );
    2685 _Complex float
    2686         ?=?( volatile float *, float ),
    2687         ?=?( _Atomic volatile float *, float );
    2688 _Complex double
    2689         ?=?( volatile double *, double ),
    2690         ?=?( _Atomic volatile double *, double );
    2691 _Complex long double
    2692         ?=?( volatile _Complex long double *, _Complex long double ),
    2693         ?=?( _Atomic volatile _Complex long double *, _Atomic _Complex long double );
    2694 
    2695 forall( ftype FT ) FT
    2696         * ?=?( FT * volatile *, FT * ),
    2697         * ?=?( FT * volatile *, forall( ftype F ) F * );
    2698 
    2699 forall( ftype FT ) FT const
    2700         * ?=?( FT const * volatile *, FT const * ),
    2701         * ?=?( FT const * volatile *, forall( ftype F ) F * );
    2702 
    2703 forall( ftype FT ) FT volatile
    2704         * ?=?( FT volatile * volatile *, FT * ),
    2705         * ?=?( FT volatile * volatile *, forall( ftype F ) F * );
    2706 
    2707 forall( ftype FT ) FT const
    2708         * ?=?( FT const volatile * volatile *, FT const * ),
    2709         * ?=?( FT const volatile * volatile *, forall( ftype F ) F * );
    2710 
    2711 forall( dtype DT ) DT
    2712         * ?=?( DT * restrict volatile *, DT * ),
    2713         * ?=?( DT * restrict volatile *, void * ),
    2714         * ?=?( DT * restrict volatile *, forall( dtype D ) D * ),
    2715         * ?=?( DT * _Atomic restrict volatile *, DT * ),
    2716         * ?=?( DT * _Atomic restrict volatile *, void * ),
    2717         * ?=?( DT * _Atomic restrict volatile *, forall( dtype D ) D * );
    2718 
    2719 forall( dtype DT ) DT _Atomic
    2720         * ?=?( _Atomic DT * restrict volatile *, DT _Atomic * ),
    2721         * ?=?( _Atomic DT * restrict volatile *, void * ),
    2722         * ?=?( _Atomic DT * restrict volatile *, forall( dtype D ) D * ),
    2723         * ?=?( _Atomic DT * _Atomic restrict volatile *, DT _Atomic * ),
    2724         * ?=?( _Atomic DT * _Atomic restrict volatile *, void * ),
    2725         * ?=?( _Atomic DT * _Atomic restrict volatile *, forall( dtype D ) D * );
    2726 
    2727 forall( dtype DT ) DT const
    2728         * ?=?( DT const * restrict volatile *, DT const * ),
    2729         * ?=?( DT const * restrict volatile *, void const * ),
    2730         * ?=?( DT const * restrict volatile *, forall( dtype D ) D * ),
    2731         * ?=?( DT const * _Atomic restrict volatile *, DT const * ),
    2732         * ?=?( DT const * _Atomic restrict volatile *, void const * ),
    2733         * ?=?( DT const * _Atomic restrict volatile *, forall( dtype D ) D * );
    2734 
    2735 forall( dtype DT ) DT restrict
    2736         * ?=?( restrict DT * restrict volatile *, DT restrict * ),
    2737         * ?=?( restrict DT * restrict volatile *, void * ),
    2738         * ?=?( restrict DT * restrict volatile *, forall( dtype D ) D * ),
    2739         * ?=?( restrict DT * _Atomic restrict volatile *, DT restrict * ),
    2740         * ?=?( restrict DT * _Atomic restrict volatile *, void * ),
    2741         * ?=?( restrict DT * _Atomic restrict volatile *, forall( dtype D ) D * );
    2742 
    2743 forall( dtype DT ) DT volatile
    2744         * ?=?( DT volatile * restrict volatile *, DT volatile * ),
    2745         * ?=?( DT volatile * restrict volatile *, void volatile * ),
    2746         * ?=?( DT volatile * restrict volatile *, forall( dtype D ) D * ),
    2747         * ?=?( DT volatile * _Atomic restrict volatile *, DT volatile * ),
    2748         * ?=?( DT volatile * _Atomic restrict volatile *, void volatile * ),
    2749         * ?=?( DT volatile * _Atomic restrict volatile *, forall( dtype D ) D * );
    2750 
    2751 forall( dtype DT ) DT _Atomic const
    2752         * ?=?( DT _Atomic const * restrict volatile *, DT _Atomic const * ),
    2753         * ?=?( DT _Atomic const * restrict volatile *, void const * ),
    2754         * ?=?( DT _Atomic const * restrict volatile *, forall( dtype D ) D * ),
    2755         * ?=?( DT _Atomic const * _Atomic restrict volatile *, DT _Atomic const * ),
    2756         * ?=?( DT _Atomic const * _Atomic restrict volatile *, void const * ),
    2757         * ?=?( DT _Atomic const * _Atomic restrict volatile *, forall( dtype D ) D * );
    2758 
    2759 forall( dtype DT ) DT _Atomic restrict
    2760         * ?=?( _Atomic restrict DT * restrict volatile *, DT _Atomic restrict * ),
    2761         * ?=?( _Atomic restrict DT * restrict volatile *, void * ),
    2762         * ?=?( _Atomic restrict DT * restrict volatile *, forall( dtype D ) D * ),
    2763         * ?=?( _Atomic restrict DT * _Atomic restrict volatile *, DT _Atomic restrict * ),
    2764         * ?=?( _Atomic restrict DT * _Atomic restrict volatile *, void * ),
    2765         * ?=?( _Atomic restrict DT * _Atomic restrict volatile *, forall( dtype D ) D * );
    2766 
    2767 forall( dtype DT ) DT _Atomic volatile
    2768         * ?=?( DT _Atomic volatile * restrict volatile *, DT _Atomic volatile * ),
    2769         * ?=?( DT _Atomic volatile * restrict volatile *, void volatile * ),
    2770         * ?=?( DT _Atomic volatile * restrict volatile *, forall( dtype D ) D * ),
    2771         * ?=?( DT _Atomic volatile * _Atomic restrict volatile *, DT _Atomic volatile * ),
    2772         * ?=?( DT _Atomic volatile * _Atomic restrict volatile *, void volatile * ),
    2773         * ?=?( DT _Atomic volatile * _Atomic restrict volatile *, forall( dtype D ) D * );
    2774 
    2775 forall( dtype DT ) DT const restrict
    2776         * ?=?( DT const restrict * restrict volatile *, DT const restrict * ),
    2777         * ?=?( DT const restrict * restrict volatile *, void const * ),
    2778         * ?=?( DT const restrict * restrict volatile *, forall( dtype D ) D * ),
    2779         * ?=?( DT const restrict * _Atomic restrict volatile *, DT const restrict * ),
    2780         * ?=?( DT const restrict * _Atomic restrict volatile *, void const * ),
    2781         * ?=?( DT const restrict * _Atomic restrict volatile *, forall( dtype D ) D * );
    2782 
    2783 forall( dtype DT ) DT const volatile
    2784         * ?=?( DT const volatile * restrict volatile *, DT const volatile * ),
    2785         * ?=?( DT const volatile * restrict volatile *, void const volatile * ),
    2786         * ?=?( DT const volatile * restrict volatile *, forall( dtype D ) D * ),
    2787         * ?=?( DT const volatile * _Atomic restrict volatile *, DT const volatile * ),
    2788         * ?=?( DT const volatile * _Atomic restrict volatile *, void const volatile * ),
    2789         * ?=?( DT const volatile * _Atomic restrict volatile *, forall( dtype D ) D * );
    2790 
    2791 forall( dtype DT ) DT restrict volatile
    2792         * ?=?( DT restrict volatile * restrict volatile *, DT restrict volatile * ),
    2793         * ?=?( DT restrict volatile * restrict volatile *, void volatile * ),
    2794         * ?=?( DT restrict volatile * restrict volatile *, forall( dtype D ) D * ),
    2795         * ?=?( DT restrict volatile * _Atomic restrict volatile *, DT restrict volatile * ),
    2796         * ?=?( DT restrict volatile * _Atomic restrict volatile *, void volatile * ),
    2797         * ?=?( DT restrict volatile * _Atomic restrict volatile *, forall( dtype D ) D * );
    2798 
    2799 forall( dtype DT ) DT _Atomic const restrict
    2800         * ?=?( DT _Atomic const restrict * restrict volatile *,
    2801          DT _Atomic const restrict * ),
    2802         * ?=?( DT _Atomic const restrict * restrict volatile *,
    2803          void const * ),
    2804         * ?=?( DT _Atomic const restrict * restrict volatile *,
    2805          forall( dtype D ) D * ),
    2806         * ?=?( DT _Atomic const restrict * _Atomic restrict volatile *,
    2807          DT _Atomic const restrict * ),
    2808         * ?=?( DT _Atomic const restrict * _Atomic restrict volatile *,
    2809          void const * ),
    2810         * ?=?( DT _Atomic const restrict * _Atomic restrict volatile *,
    2811          forall( dtype D ) D * );
    2812 
    2813 forall( dtype DT ) DT _Atomic const volatile
    2814         * ?=?( DT _Atomic const volatile * restrict volatile *,
    2815          DT _Atomic const volatile * ),
    2816         * ?=?( DT _Atomic const volatile * restrict volatile *,
    2817          void const volatile * ),
    2818         * ?=?( DT _Atomic const volatile * restrict volatile *,
    2819          forall( dtype D ) D * ),
    2820         * ?=?( DT _Atomic const volatile * _Atomic restrict volatile *,
    2821          DT _Atomic const volatile * ),
    2822         * ?=?( DT _Atomic const volatile * _Atomic restrict volatile *,
    2823          void const volatile * ),
    2824         * ?=?( DT _Atomic const volatile * _Atomic restrict volatile *,
    2825          forall( dtype D ) D * );
    2826 
    2827 forall( dtype DT ) DT _Atomic restrict volatile
    2828         * ?=?( DT _Atomic restrict volatile * restrict volatile *,
    2829          DT _Atomic restrict volatile * ),
    2830         * ?=?( DT _Atomic restrict volatile * restrict volatile *,
    2831          void volatile * ),
    2832         * ?=?( DT _Atomic restrict volatile * restrict volatile *,
    2833          forall( dtype D ) D * ),
    2834         * ?=?( DT _Atomic restrict volatile * _Atomic restrict volatile *,
    2835          DT _Atomic restrict volatile * ),
    2836         * ?=?( DT _Atomic restrict volatile * _Atomic restrict volatile *,
    2837          void volatile * ),
    2838         * ?=?( DT _Atomic restrict volatile * _Atomic restrict volatile *,
    2839          forall( dtype D ) D * );
    2840 
    2841 forall( dtype DT ) DT const restrict volatile
    2842         * ?=?( DT const restrict volatile * restrict volatile *,
    2843          DT const restrict volatile * ),
    2844         * ?=?( DT const restrict volatile * restrict volatile *,
    2845          void const volatile * ),
    2846         * ?=?( DT const restrict volatile * restrict volatile *,
    2847          forall( dtype D ) D * ),
    2848         * ?=?( DT const restrict volatile * _Atomic restrict volatile *,
    2849          DT const restrict volatile * ),
    2850         * ?=?( DT const restrict volatile * _Atomic restrict volatile *,
    2851          void const volatile * ),
    2852         * ?=?( DT const restrict volatile * _Atomic restrict volatile *,
    2853          forall( dtype D ) D * );
    2854 
    2855 forall( dtype DT ) DT _Atomic const restrict volatile
    2856         * ?=?( DT _Atomic const restrict volatile * restrict volatile *,
    2857          DT _Atomic const restrict volatile * ),
    2858         * ?=?( DT _Atomic const restrict volatile * restrict volatile *,
    2859          void const volatile * ),
    2860         * ?=?( DT _Atomic const restrict volatile * restrict volatile *,
    2861          forall( dtype D ) D * ),
    2862         * ?=?( DT _Atomic const restrict volatile * _Atomic restrict volatile *,
    2863          DT _Atomic const restrict volatile * ),
    2864         * ?=?( DT _Atomic const restrict volatile * _Atomic restrict volatile *,
    2865          void const volatile * ),
    2866         * ?=?( DT _Atomic const restrict volatile * _Atomic restrict volatile *,
    2867          forall( dtype D ) D * );
    2868 
    2869 forall( dtype DT ) void
    2870         * ?=?( void * restrict volatile *, DT * );
    2871 
    2872 forall( dtype DT ) void const
    2873         * ?=?( void const * restrict volatile *, DT const * );
    2874 
    2875 forall( dtype DT ) void volatile
    2876         * ?=?( void volatile * restrict volatile *, DT volatile * );
    2877 
    2878 forall( dtype DT ) void const volatile
    2879         * ?=?( void const volatile * restrict volatile *, DT const volatile * );
    2880 \end{lstlisting}
    2881 \begin{rationale}
    2882 The pattern of overloadings for simple assignment resembles that of pointer increment and decrement,
    2883 except that the polymorphic pointer assignment functions declare a \lstinline$dtype$ parameter,
    2884 instead of a \lstinline$type$ parameter, because the left operand may be a pointer to an incomplete
    2885 type.
    2886 \end{rationale}
    2887 
    2888 For every complete structure or union type \lstinline$S$ there exist
    2889 % Don't use predefined: keep this out of prelude.cf.
    2890 \begin{lstlisting}
    2891 S ?=?( S volatile *, S ), ?=?( S _Atomic volatile *, S );
    2892 \end{lstlisting}
    2893 
    2894 For every extended integer type \lstinline$X$ there exist
    2895 % Don't use predefined: keep this out of prelude.cf.
    2896 \begin{lstlisting}
    2897 X ?=?( X volatile *, X ), ?=?( X _Atomic volatile *, X );
    2898 \end{lstlisting}
    2899 
    2900 For every complete enumerated type \lstinline$E$ there exist
    2901 % Don't use predefined: keep this out of prelude.cf.
    2902 \begin{lstlisting}
    2903 E ?=?( E volatile *, int ), ?=?( E _Atomic volatile *, int );
    2904 \end{lstlisting}
    2905 \begin{rationale}
    2906 The right-hand argument is \lstinline$int$ because enumeration constants have type \lstinline$int$.
    2907 \end{rationale}
    2908 
    2909 \semantics
    2910 The structure assignment functions provide member-wise assignment; each non-array member and each
    2911 element of each array member of the right argument is assigned to the corresponding member or
    2912 element of the left argument using the assignment function defined for its type. All other
    2913 assignment functions have the same effect as the corresponding C assignment expression.
    2914 \begin{rationale}
    2915 Note that, by default, union assignment\index{deficiencies!union assignment} uses C semantics---that
    2916 is, bitwise copy---even if some of the union members have programmer-defined assignment functions.
    2917 \end{rationale}
    2918 
    2919 
    2920 \subsubsection{Compound assignment}
    2921 
    2922 \begin{lstlisting}
    2923 forall( type T ) T
    2924         * ?+=?( T * restrict volatile *, ptrdiff_t ),
    2925         * ?-=?( T * restrict volatile *, ptrdiff_t ),
    2926         * ?+=?( T * _Atomic restrict volatile *, ptrdiff_t ),
    2927         * ?-=?( T * _Atomic restrict volatile *, ptrdiff_t );
    2928 
    2929 forall( type T ) T _Atomic
    2930         * ?+=?( T _Atomic * restrict volatile *, ptrdiff_t ),
    2931         * ?-=?( T _Atomic * restrict volatile *, ptrdiff_t ),
    2932         * ?+=?( T _Atomic * _Atomic restrict volatile *, ptrdiff_t ),
    2933         * ?-=?( T _Atomic * _Atomic restrict volatile *, ptrdiff_t );
    2934 
    2935 forall( type T ) T const
    2936         * ?+=?( T const * restrict volatile *, ptrdiff_t ),
    2937         * ?-=?( T const * restrict volatile *, ptrdiff_t ),
    2938         * ?+=?( T const * _Atomic restrict volatile *, ptrdiff_t ),
    2939         * ?-=?( T const * _Atomic restrict volatile *, ptrdiff_t );
    2940 
    2941 forall( type T ) T restrict
    2942         * ?+=?( T restrict * restrict volatile *, ptrdiff_t ),
    2943         * ?-=?( T restrict * restrict volatile *, ptrdiff_t ),
    2944         * ?+=?( T restrict * _Atomic restrict volatile *, ptrdiff_t ),
    2945         * ?-=?( T restrict * _Atomic restrict volatile *, ptrdiff_t );
    2946 
    2947 forall( type T ) T volatile
    2948         * ?+=?( T volatile * restrict volatile *, ptrdiff_t ),
    2949         * ?-=?( T volatile * restrict volatile *, ptrdiff_t ),
    2950         * ?+=?( T volatile * _Atomic restrict volatile *, ptrdiff_t ),
    2951         * ?-=?( T volatile * _Atomic restrict volatile *, ptrdiff_t );
    2952 
    2953 forall( type T ) T _Atomic const
    2954         * ?+=?( T _Atomic const restrict volatile *, ptrdiff_t ),
    2955         * ?-=?( T _Atomic const restrict volatile *, ptrdiff_t ),
    2956         * ?+=?( T _Atomic const _Atomic restrict volatile *, ptrdiff_t ),
    2957         * ?-=?( T _Atomic const _Atomic restrict volatile *, ptrdiff_t );
    2958 
    2959 forall( type T ) T _Atomic restrict
    2960         * ?+=?( T _Atomic restrict * restrict volatile *, ptrdiff_t ),
    2961         * ?-=?( T _Atomic restrict * restrict volatile *, ptrdiff_t ),
    2962         * ?+=?( T _Atomic restrict * _Atomic restrict volatile *, ptrdiff_t ),
    2963         * ?-=?( T _Atomic restrict * _Atomic restrict volatile *, ptrdiff_t );
    2964 
    2965 forall( type T ) T _Atomic volatile
    2966         * ?+=?( T _Atomic volatile * restrict volatile *, ptrdiff_t ),
    2967         * ?-=?( T _Atomic volatile * restrict volatile *, ptrdiff_t ),
    2968         * ?+=?( T _Atomic volatile * _Atomic restrict volatile *, ptrdiff_t ),
    2969         * ?-=?( T _Atomic volatile * _Atomic restrict volatile *, ptrdiff_t );
    2970 
    2971 forall( type T ) T const restrict
    2972         * ?+=?( T const restrict * restrict volatile *, ptrdiff_t ),
    2973         * ?-=?( T const restrict * restrict volatile *, ptrdiff_t ),
    2974         * ?+=?( T const restrict * _Atomic restrict volatile *, ptrdiff_t ),
    2975         * ?-=?( T const restrict * _Atomic restrict volatile *, ptrdiff_t );
    2976 
    2977 forall( type T ) T const volatile
    2978         * ?+=?( T const volatile * restrict volatile *, ptrdiff_t ),
    2979         * ?-=?( T const volatile * restrict volatile *, ptrdiff_t ),
    2980         * ?+=?( T const volatile * _Atomic restrict volatile *, ptrdiff_t ),
    2981         * ?-=?( T const volatile * _Atomic restrict volatile *, ptrdiff_t );
    2982 
    2983 forall( type T ) T restrict volatile
    2984         * ?+=?( T restrict volatile * restrict volatile *, ptrdiff_t ),
    2985         * ?-=?( T restrict volatile * restrict volatile *, ptrdiff_t ),
    2986         * ?+=?( T restrict volatile * _Atomic restrict volatile *, ptrdiff_t ),
    2987         * ?-=?( T restrict volatile * _Atomic restrict volatile *, ptrdiff_t );
    2988 
    2989 forall( type T ) T _Atomic const restrict
    2990         * ?+=?( T _Atomic const restrict * restrict volatile *, ptrdiff_t ),
    2991         * ?-=?( T _Atomic const restrict * restrict volatile *, ptrdiff_t ),
    2992         * ?+=?( T _Atomic const restrict * _Atomic restrict volatile *, ptrdiff_t ),
    2993         * ?-=?( T _Atomic const restrict * _Atomic restrict volatile *, ptrdiff_t );
    2994 
    2995 forall( type T ) T _Atomic const volatile
    2996         * ?+=?( T _Atomic const volatile * restrict volatile *, ptrdiff_t ),
    2997         * ?-=?( T _Atomic const volatile * restrict volatile *, ptrdiff_t ),
    2998         * ?+=?( T _Atomic const volatile * _Atomic restrict volatile *, ptrdiff_t ),
    2999         * ?-=?( T _Atomic const volatile * _Atomic restrict volatile *, ptrdiff_t );
    3000 
    3001 forall( type T ) T _Atomic restrict volatile
    3002         * ?+=?( T _Atomic restrict volatile * restrict volatile *, ptrdiff_t ),
    3003         * ?-=?( T _Atomic restrict volatile * restrict volatile *, ptrdiff_t ),
    3004         * ?+=?( T _Atomic restrict volatile * _Atomic restrict volatile *, ptrdiff_t ),
    3005         * ?-=?( T _Atomic restrict volatile * _Atomic restrict volatile *, ptrdiff_t );
    3006 
    3007 forall( type T ) T const restrict volatile
    3008         * ?+=?( T const restrict volatile * restrict volatile *, ptrdiff_t ),
    3009         * ?-=?( T const restrict volatile * restrict volatile *, ptrdiff_t ),
    3010         * ?+=?( T const restrict volatile * _Atomic restrict volatile *, ptrdiff_t ),
    3011         * ?-=?( T const restrict volatile * _Atomic restrict volatile *, ptrdiff_t );
    3012 
    3013 forall( type T ) T _Atomic const restrict volatile
    3014         * ?+=?( T _Atomic const restrict volatile * restrict volatile *, ptrdiff_t ),
    3015         * ?-=?( T _Atomic const restrict volatile * restrict volatile *, ptrdiff_t ),
    3016         * ?+=?( T _Atomic const restrict volatile * _Atomic restrict volatile *, ptrdiff_t ),
    3017         * ?-=?( T _Atomic const restrict volatile * _Atomic restrict volatile *, ptrdiff_t );
    3018 
    3019 _Bool
    3020         ?*=?( _Bool volatile *, _Bool ),
    3021         ?/=?( _Bool volatile *, _Bool ),
    3022         ?+=?( _Bool volatile *, _Bool ),
    3023         ?-=?( _Bool volatile *, _Bool ),
    3024         ?%=?( _Bool volatile *, _Bool ),
    3025         ?<<=?( _Bool volatile *, int ),
    3026         ?>>=?( _Bool volatile *, int ),
    3027         ?&=?( _Bool volatile *, _Bool ),
    3028         ?^=?( _Bool volatile *, _Bool ),
    3029         ?|=?( _Bool volatile *, _Bool );
    3030 char
    3031         ?*=?( char volatile *, char ),
    3032         ?/=?( char volatile *, char ),
    3033         ?+=?( char volatile *, char ),
    3034         ?-=?( char volatile *, char ),
    3035         ?%=?( char volatile *, char ),
    3036         ?<<=?( char volatile *, int ),
    3037         ?>>=?( char volatile *, int ),
    3038         ?&=?( char volatile *, char ),
    3039         ?^=?( char volatile *, char ),
    3040         ?|=?( char volatile *, char );
    3041 unsigned char
    3042         ?*=?( unsigned char volatile *, unsigned char ),
    3043         ?/=?( unsigned char volatile *, unsigned char ),
    3044         ?+=?( unsigned char volatile *, unsigned char ),
    3045         ?-=?( unsigned char volatile *, unsigned char ),
    3046         ?%=?( unsigned char volatile *, unsigned char ),
    3047         ?<<=?( unsigned char volatile *, int ),
    3048         ?>>=?( unsigned char volatile *, int ),
    3049         ?&=?( unsigned char volatile *, unsigned char ),
    3050         ?^=?( unsigned char volatile *, unsigned char ),
    3051         ?|=?( unsigned char volatile *, unsigned char );
    3052 signed char
    3053         ?*=?( signed char volatile *, signed char ),
    3054         ?/=?( signed char volatile *, signed char ),
    3055         ?+=?( signed char volatile *, signed char ),
    3056         ?-=?( signed char volatile *, signed char ),
    3057         ?%=?( signed char volatile *, signed char ),
    3058         ?<<=?( signed char volatile *, int ),
    3059         ?>>=?( signed char volatile *, int ),
    3060         ?&=?( signed char volatile *, signed char ),
    3061         ?^=?( signed char volatile *, signed char ),
    3062         ?|=?( signed char volatile *, signed char );
    3063 short int
    3064         ?*=?( short int volatile *, short int ),
    3065         ?/=?( short int volatile *, short int ),
    3066         ?+=?( short int volatile *, short int ),
    3067         ?-=?( short int volatile *, short int ),
    3068         ?%=?( short int volatile *, short int ),
    3069         ?<<=?( short int volatile *, int ),
    3070         ?>>=?( short int volatile *, int ),
    3071         ?&=?( short int volatile *, short int ),
    3072         ?^=?( short int volatile *, short int ),
    3073         ?|=?( short int volatile *, short int );
    3074 unsigned short int
    3075         ?*=?( unsigned short int volatile *, unsigned short int ),
    3076         ?/=?( unsigned short int volatile *, unsigned short int ),
    3077         ?+=?( unsigned short int volatile *, unsigned short int ),
    3078         ?-=?( unsigned short int volatile *, unsigned short int ),
    3079         ?%=?( unsigned short int volatile *, unsigned short int ),
    3080         ?<<=?( unsigned short int volatile *, int ),
    3081         ?>>=?( unsigned short int volatile *, int ),
    3082         ?&=?( unsigned short int volatile *, unsigned short int ),
    3083         ?^=?( unsigned short int volatile *, unsigned short int ),
    3084         ?|=?( unsigned short int volatile *, unsigned short int );
    3085 int
    3086         ?*=?( int volatile *, int ),
    3087         ?/=?( int volatile *, int ),
    3088         ?+=?( int volatile *, int ),
    3089         ?-=?( int volatile *, int ),
    3090         ?%=?( int volatile *, int ),
    3091         ?<<=?( int volatile *, int ),
    3092         ?>>=?( int volatile *, int ),
    3093         ?&=?( int volatile *, int ),
    3094         ?^=?( int volatile *, int ),
    3095         ?|=?( int volatile *, int );
    3096 unsigned int
    3097         ?*=?( unsigned int volatile *, unsigned int ),
    3098         ?/=?( unsigned int volatile *, unsigned int ),
    3099         ?+=?( unsigned int volatile *, unsigned int ),
    3100         ?-=?( unsigned int volatile *, unsigned int ),
    3101         ?%=?( unsigned int volatile *, unsigned int ),
    3102         ?<<=?( unsigned int volatile *, int ),
    3103         ?>>=?( unsigned int volatile *, int ),
    3104         ?&=?( unsigned int volatile *, unsigned int ),
    3105         ?^=?( unsigned int volatile *, unsigned int ),
    3106         ?|=?( unsigned int volatile *, unsigned int );
    3107 long int
    3108         ?*=?( long int volatile *, long int ),
    3109         ?/=?( long int volatile *, long int ),
    3110         ?+=?( long int volatile *, long int ),
    3111         ?-=?( long int volatile *, long int ),
    3112         ?%=?( long int volatile *, long int ),
    3113         ?<<=?( long int volatile *, int ),
    3114         ?>>=?( long int volatile *, int ),
    3115         ?&=?( long int volatile *, long int ),
    3116         ?^=?( long int volatile *, long int ),
    3117         ?|=?( long int volatile *, long int );
    3118 unsigned long int
    3119         ?*=?( unsigned long int volatile *, unsigned long int ),
    3120         ?/=?( unsigned long int volatile *, unsigned long int ),
    3121         ?+=?( unsigned long int volatile *, unsigned long int ),
    3122         ?-=?( unsigned long int volatile *, unsigned long int ),
    3123         ?%=?( unsigned long int volatile *, unsigned long int ),
    3124         ?<<=?( unsigned long int volatile *, int ),
    3125         ?>>=?( unsigned long int volatile *, int ),
    3126         ?&=?( unsigned long int volatile *, unsigned long int ),
    3127         ?^=?( unsigned long int volatile *, unsigned long int ),
    3128         ?|=?( unsigned long int volatile *, unsigned long int );
    3129 long long int
    3130         ?*=?( long long int volatile *, long long int ),
    3131         ?/=?( long long int volatile *, long long int ),
    3132         ?+=?( long long int volatile *, long long int ),
    3133         ?-=?( long long int volatile *, long long int ),
    3134         ?%=?( long long int volatile *, long long int ),
    3135         ?<<=?( long long int volatile *, int ),
    3136         ?>>=?( long long int volatile *, int ),
    3137         ?&=?( long long int volatile *, long long int ),
    3138         ?^=?( long long int volatile *, long long int ),
    3139         ?|=?( long long int volatile *, long long int );
    3140 unsigned long long int
    3141         ?*=?( unsigned long long int volatile *, unsigned long long int ),
    3142         ?/=?( unsigned long long int volatile *, unsigned long long int ),
    3143         ?+=?( unsigned long long int volatile *, unsigned long long int ),
    3144         ?-=?( unsigned long long int volatile *, unsigned long long int ),
    3145         ?%=?( unsigned long long int volatile *, unsigned long long int ),
    3146         ?<<=?( unsigned long long int volatile *, int ),
    3147         ?>>=?( unsigned long long int volatile *, int ),
    3148         ?&=?( unsigned long long int volatile *, unsigned long long int ),
    3149         ?^=?( unsigned long long int volatile *, unsigned long long int ),
    3150         ?|=?( unsigned long long int volatile *, unsigned long long int );
    3151 float
    3152         ?*=?( float volatile *, float ),
    3153         ?/=?( float volatile *, float ),
    3154         ?+=?( float volatile *, float ),
    3155         ?-=?( float volatile *, float );
    3156 double
    3157         ?*=?( double volatile *, double ),
    3158         ?/=?( double volatile *, double ),
    3159         ?+=?( double volatile *, double ),
    3160         ?-=?( double volatile *, double );
    3161 long double
    3162         ?*=?( long double volatile *, long double ),
    3163         ?/=?( long double volatile *, long double ),
    3164         ?+=?( long double volatile *, long double ),
    3165         ?-=?( long double volatile *, long double );
    3166 _Complex float
    3167         ?*=?( _Complex float volatile *, _Complex float ),
    3168         ?/=?( _Complex float volatile *, _Complex float ),
    3169         ?+=?( _Complex float volatile *, _Complex float ),
    3170         ?-=?( _Complex float volatile *, _Complex float );
    3171 _Complex double
    3172         ?*=?( _Complex double volatile *, _Complex double ),
    3173         ?/=?( _Complex double volatile *, _Complex double ),
    3174         ?+=?( _Complex double volatile *, _Complex double ),
    3175         ?-=?( _Complex double volatile *, _Complex double );
    3176 _Complex long double
    3177         ?*=?( _Complex long double volatile *, _Complex long double ),
    3178         ?/=?( _Complex long double volatile *, _Complex long double ),
    3179         ?+=?( _Complex long double volatile *, _Complex long double ),
    3180         ?-=?( _Complex long double volatile *, _Complex long double );
    3181 \end{lstlisting}
    3182 
    3183 For every extended integer type \lstinline$X$ there exist
    3184 % Don't use predefined: keep this out of prelude.cf.
    3185 \begin{lstlisting}
    3186 ?*=?( X volatile *, X ),
    3187 ?/=?( X volatile *, X ),
    3188 ?+=?( X volatile *, X ),
    3189 ?-=?( X volatile *, X ),
    3190 ?%=?( X volatile *, X ),
    3191 ?<<=?( X volatile *, int ),
    3192 ?>>=?( X volatile *, int ),
    3193 ?&=?( X volatile *, X ),
    3194 ?^=?( X volatile *, X ),
    3195 ?|=?( X volatile *, X );
    3196 \end{lstlisting}
    3197 
    3198 For every complete enumerated type \lstinline$E$ there exist
    3199 % Don't use predefined: keep this out of prelude.cf.
    3200 \begin{lstlisting}
    3201 ?*=?( E volatile *, E ),
    3202 ?/=?( E volatile *, E ),
    3203 ?+=?( E volatile *, E ),
    3204 ?-=?( E volatile *, E ),
    3205 ?%=?( E volatile *, E ),
    3206 ?<<=?( E volatile *, int ),
    3207 ?>>=?( E volatile *, int ),
    3208 ?&=?( E volatile *, E ),
    3209 ?^=?( E volatile *, E ),
    3210 ?|=?( E volatile *, E );
    3211 \end{lstlisting}
    3212 
    3213 
    3214 \subsection{Comma operator}
    3215 
    3216 \begin{syntax}
    3217 \lhs{expression}
    3218 \rhs \nonterm{assignment-expression}
    3219 \rhs \nonterm{expression} \lstinline$,$ \nonterm{assignment-expression}
    3220 \end{syntax}
    3221 
    3222 \semantics
    3223 In the comma expression ``\lstinline$a, b$'', the first operand is interpreted as
    3224 ``\lstinline$( void )(a)$'', which shall be unambiguous\index{ambiguous interpretation}. The
    3225 interpretations of the expression are the interpretations of the second operand.
    3226 
    3227 
    3228 \section{Constant expressions}
    3229 
    3230 
    3231 \section{Declarations}
    3232 
    3233 \begin{syntax}
    3234 \oldlhs{declaration}
    3235 \rhs \nonterm{type-declaration}
    3236 \rhs \nonterm{spec-definition}
    3237 \end{syntax}
    3238 
    3239 \constraints
    3240 If an identifier has \Index{no linkage}, there shall be no more than one declaration of the
    3241 identifier ( in a declarator or type specifier ) with compatible types in the same scope and in the
    3242 same name space, except that:
    3243 \begin{itemize}
    3244 \item
    3245 a typedef name may be redefined to denote the same type as it currently does, provided that type is
    3246 not a variably modified type;
    3247 \item
    3248 tags may be redeclared as specified in section 6.7.2.3 of the {\c11} standard.
    3249 \end{itemize}
    3250 \begin{rationale}
    3251 This constraint adds the phrase ``with compatible types'' to the {\c11} constraint, to allow
    3252 overloading.
    3253 \end{rationale}
    3254 
    3255 An identifier declared by a type declaration shall not be redeclared as a parameter in a function
    3256 definition whose declarator includes an identifier list.
    3257 \begin{rationale}
    3258 This restriction echos {\c11}'s ban on the redeclaration of typedef names as parameters. This
    3259 avoids an ambiguity between old-style function declarations and new-style function prototypes:
    3260 \begin{lstlisting}
    3261 void f( Complex,        // ... 3000 characters ...
    3262 void g( Complex,        // ... 3000 characters ...
    3263 int Complex; { ... }
    3264 \end{lstlisting}
    3265 Without the rule, \lstinline$Complex$ would be a type in the first case, and a parameter name in the
    3266 second.
    3267 \end{rationale}
    3268 
    3269 
    3270 \setcounter{subsection}{1}
    3271 \subsection{Type specifiers}
    3272 
    3273 \begin{syntax}
    3274 \oldlhs{type-specifier}
    3275 \rhs \nonterm{forall-specifier}
    3276 \end{syntax}
    3277 
    3278 \semantics
    3279 Forall specifiers are discussed in \VRef{forall}.
    3280 
    3281 
    3282 \subsubsection{Structure and union specifiers}
    3283 
    3284 \semantics
    3285 \CFA extends the {\c11} definition of \define{anonymous structure} to include structure
    3286 specifiers with tags, and extends the {\c11} definition of \define{anonymous union} to include union
    3287 specifiers with tags.
    3288 \begin{rationale}
    3289 This extension imitates an extension in the Plan 9 C compiler \cite{Thompson90new}.
    3290 \end{rationale}
    3291 
    3292 \examples
    3293 \begin{lstlisting}
    3294 struct point {@\impl{point}@
    3295         int x, y;
    3296 };
    3297 struct color_point {@\impl{color_point}@
    3298         enum { RED, BLUE, GREEN } color;
    3299         struct point;
    3300 };
    3301 struct color_point cp;
    3302 cp.x = 0;
    3303 cp.color = RED;
    3304 
    3305 struct literal {@\impl{literal}@
    3306         enum { NUMBER, STRING } tag;
    3307         union {
    3308          double n;
    3309          char *s;
    3310         };
    3311 };
    3312 struct literal *next;
    3313 int length;
    3314 extern int strlen( const char * );
    3315 ...
    3316 if ( next->tag == STRING ) length = strlen( next->s );
    3317 \end{lstlisting}
    3318 
    3319 
    3320 \setcounter{subsubsection}{4}
    3321 \subsubsection{Forall specifiers}\label{forall}
    3322 
    3323 \begin{syntax}
    3324 \lhs{forall-specifier}
    3325 \rhs \lstinline$forall$ \lstinline$($ \nonterm{type-parameter-list} \lstinline$)$
    3326 \end{syntax}
    3327 
    3328 \constraints
    3329 If the \nonterm{declaration-specifiers} of a declaration that contains a \nonterm{forall-specifier}
    3330 declares a structure or union tag, the types of the members of the structure or union shall not use
    3331 any of the type identifiers declared by the \nonterm{type-parameter-list}.
    3332 \begin{rationale}
    3333 This sort of declaration is illegal because the scope of the type identifiers ends at the end of the
    3334 declaration, but the scope of the structure tag does not.
    3335 \begin{lstlisting}
    3336 forall( type T ) struct Pair { T a, b; } mkPair( T, T ); // illegal
    3337 \end{lstlisting}
    3338 If an instance of \lstinline$struct Pair$ was declared later in the current scope, what would the
    3339 members' type be?
    3340 \end{rationale}
    3341 
    3342 \semantics
    3343 The \nonterm{type-parameter-list}s and assertions of the \nonterm{forall-specifier}s declare type
    3344 identifiers, function and object identifiers with \Index{no linkage}.
    3345 
    3346 If, in the declaration ``\lstinline$T D1$'', \lstinline$T$ contains \nonterm{forall-specifier}s and
    3347 \lstinline$D1$ has the form
    3348 \begin{lstlisting}
    3349 D( @\normalsize\nonterm{parameter-type-list}@ )
    3350 \end{lstlisting}
    3351 then a type identifier declared by one of the \nonterm{forall-specifier}s is an \define{inferred
    3352 parameter} of the function declarator if and only if it is not an inferred parameter of a function
    3353 declarator in \lstinline$D$, and it is used in the type of a parameter in the following
    3354 \nonterm{type-parameter-list} or it and an inferred parameter are used as arguments of a
    3355 \Index{specification} in one of the \nonterm{forall-specifier}s. The identifiers declared by
    3356 assertions that use an inferred parameter of a function declarator are \Index{assertion parameter}s
    3357 of that function declarator.
    3358 \begin{rationale}
    3359 Since every inferred parameter is used by some parameter, inference can be understood as a single
    3360 bottom-up pass over the expression tree, that only needs to apply local reasoning at each node.
    3361 
    3362 If this restriction were lifted, it would be possible to write
    3363 \begin{lstlisting}
    3364 forall( type T ) T * alloc( void );@\use{alloc}@
    3365 int *p = alloc();
    3366 \end{lstlisting}
    3367 Here \lstinline$alloc()$ would receive \lstinline$int$ as an inferred argument, and return an
    3368 \lstinline$int *$. In general, if a call to \lstinline$alloc()$ is a subexpression of an expression
    3369 involving polymorphic functions and overloaded identifiers, there could be considerable distance
    3370 between the call and the subexpression that causes \lstinline$T$ to be bound.
    3371 
    3372 With the current restriction, \lstinline$alloc()$ must be given an argument that determines
    3373 \lstinline$T$:
    3374 \begin{lstlisting}
    3375 forall( type T ) T * alloc( T initial_value );@\use{alloc}@
    3376 \end{lstlisting}
    3377 \end{rationale}
    3378 
    3379 If a function declarator is part of a function definition, its inferred parameters and assertion
    3380 parameters have \Index{block scope}; otherwise, identifiers declared by assertions have a
    3381 \define{declaration scope}, which terminates at the end of the \nonterm{declaration}.
    3382 
    3383 A function type that has at least one inferred parameter is a \define{polymorphic function} type.
    3384 Function types with no inferred parameters are \define{monomorphic function} types. One function
    3385 type is \define{less polymorphic} than another if it has fewer inferred parameters, or if it has the
    3386 same number of inferred parameters and fewer of its explicit parameters have types that depend on an
    3387 inferred parameter.
    3388 
    3389 The names of inferred parameters and the order of identifiers in forall specifiers are not relevant
    3390 to polymorphic function type compatibility. Let $f$ and $g$ be two polymorphic function types with
    3391 the same number of inferred parameters, and let $f_i$ and $g_i$ be the inferred parameters of $f$
    3392 and $g$ in their order of occurance in the function types' \nonterm{parameter-type-list}s. Let $f'$
    3393 be $f$ with every occurrence of $f_i$ replaced by $g_i$, for all $i$. Then $f$ and $g$ are
    3394 \Index{compatible type}s if $f'$'s and $g$'s return types and parameter lists are compatible, and if
    3395 for every assertion parameter of $f'$ there is an assertion parameter in $g$ with the same
    3396 identifier and compatible type, and vice versa.
    3397 
    3398 \examples
    3399 Consider these analogous monomorphic and polymorphic declarations.
    3400 \begin{lstlisting}
    3401 int fi( int );
    3402 forall( type T ) T fT( T );
    3403 \end{lstlisting}
    3404 \lstinline$fi()$ takes an \lstinline$int$ and returns an \lstinline$int$. \lstinline$fT()$ takes a
    3405 \lstinline$T$ and returns a \lstinline$T$, for any type \lstinline$T$.
    3406 \begin{lstlisting}
    3407 int (*pfi )( int ) = fi;
    3408 forall( type T ) T (*pfT )( T ) = fT;
    3409 \end{lstlisting}
    3410 \lstinline$pfi$ and \lstinline$pfT$ are pointers to functions. \lstinline$pfT$ is not
    3411 polymorphic, but the function it points at is.
    3412 \begin{lstlisting}
    3413 int (*fvpfi( void ))( int ) {
    3414         return pfi;
    3415 }
    3416 forall( type T ) T (*fvpfT( void ))( T ) {
    3417         return pfT;
    3418 }
    3419 \end{lstlisting}
    3420 \lstinline$fvpfi()$ and \lstinline$fvpfT()$ are functions taking no arguments and returning pointers
    3421 to functions. \lstinline$fvpfT()$ is monomorphic, but the function that its return value points
    3422 at is polymorphic.
    3423 \begin{lstlisting}
    3424 forall( type T ) int ( *fTpfi( T ) )( int );
    3425 forall( type T ) T ( *fTpfT( T ) )( T );
    3426 forall( type T, type U ) U ( *fTpfU( T ) )( U );
    3427 \end{lstlisting}
    3428 \lstinline$fTpfi()$ is a polymorphic function that returns a pointer to a monomorphic function
    3429 taking an integer and returning an integer. It could return \lstinline$pfi$. \lstinline$fTpfT()$
    3430 is subtle: it is a polymorphic function returning a \emph{monomorphic} function taking and returning
    3431 \lstinline$T$, where \lstinline$T$ is an inferred parameter of \lstinline$fTpfT()$. For instance,
    3432 in the expression ``\lstinline$fTpfT(17)$'', \lstinline$T$ is inferred to be \lstinline$int$, and
    3433 the returned value would have type \lstinline$int ( * )( int )$. ``\lstinline$fTpfT(17)(13)$'' and
    3434 ``\lstinline$fTpfT("yes")("no")$'' are legal, but ``\lstinline$fTpfT(17)("no")$'' is illegal.
    3435 \lstinline$fTpfU()$ is polymorphic ( in type \lstinline$T$), and returns a pointer to a function that
    3436 is polymorphic ( in type \lstinline$U$). ``\lstinline$f5(17)("no")$'' is a legal expression of type
    3437 \lstinline$char *$.
    3438 \begin{lstlisting}
    3439 forall( type T, type U, type V ) U * f( T *, U, V * const );
    3440 forall( type U, type V, type W ) U * g( V *, U, W * const );
    3441 \end{lstlisting}
    3442 The functions \lstinline$f()$ and \lstinline$g()$ have compatible types. Let \(f\) and \(g\) be
    3443 their types; then \(f_1\) = \lstinline$T$, \(f_2\) = \lstinline$U$, \(f_3\) = \lstinline$V$, \(g_1\)
    3444 = \lstinline$V$, \(g_2\) = \lstinline$U$, and \(g_3\) = \lstinline$W$. Replacing every \(f_i\)
    3445 by \(g_i\) in \(f\) gives
    3446 \begin{lstlisting}
    3447 forall( type V, type U, type W ) U * f( V *, U, W * const );
    3448 \end{lstlisting}
    3449 which has a return type and parameter list that is compatible with \(g\).
    3450 \begin{rationale}
    3451 The word ``\lstinline$type$'' in a forall specifier is redundant at the moment, but I want to leave
    3452 room for inferred parameters of ordinary types in case parameterized types get added one day.
    3453 
    3454 Even without parameterized types, I might try to allow
    3455 \begin{lstlisting}
    3456 forall( int n ) int sum( int vector[n] );
    3457 \end{lstlisting}
    3458 but C currently rewrites array parameters as pointer parameters, so the effects of such a change
    3459 require more thought.
    3460 \end{rationale}
    3461 
    3462 \begin{rationale}
    3463 A polymorphic declaration must do two things: it must introduce type parameters, and it must apply
    3464 assertions to those types. Adding this to existing C declaration syntax and semantics was delicate,
    3465 and not entirely successful.
    3466 
    3467 C depends on declaration-before-use, so a forall specifier must introduce type names before they can
    3468 be used in the declaration specifiers. This could be done by making the forall specifier part of
    3469 the declaration specifiers, or by making it a new introductory clause of declarations.
    3470 
    3471 Assertions are also part of polymorphic function types, because it must be clear which functions
    3472 have access to the assertion parameters declared by the assertions. All attempts to put assertions
    3473 inside an introductory clause produced complex semantics and confusing code. Building them into the
    3474 declaration specifiers could be done by placing them in the function's parameter list, or in a
    3475 forall specifier that is a declaration specifier. Assertions are also used with type parameters of
    3476 specifications, and by type declarations. For consistency's sake it seems best to attach assertions
    3477 to the type declarations in forall specifiers, which means that forall specifiers must be
    3478 declaration specifiers.
    3479 \end{rationale}
    3480 %HERE
    3481 
    3482 
    3483 \subsection{Type qualifiers}
    3484 
    3485 \CFA defines a new type qualifier \lstinline$lvalue$\impl{lvalue}\index{lvalue}.
    3486 \begin{syntax}
    3487 \oldlhs{type-qualifier}
    3488 \rhs \lstinline$lvalue$
    3489 \end{syntax}
    3490 
    3491 \constraints
    3492 \lstinline$restrict$\index{register@{\lstinline$restrict$}} Types other than type parameters and
    3493 pointer types whose referenced type is an object type shall not be restrict-qualified.
    3494 
    3495 \semantics
    3496 An object's type may be a restrict-qualified type parameter. \lstinline$restrict$ does not
    3497 establish any special semantics in that case.
    3498 
    3499 \begin{rationale}
    3500 \CFA loosens the constraint on the restrict qualifier so that restrict-qualified pointers may be
    3501 passed to polymorphic functions.
    3502 \end{rationale}
    3503 
    3504 \lstinline$lvalue$ may be used to qualify the return type of a function type. Let \lstinline$T$ be
    3505 an unqualified version of a type; then the result of calling a function with return type
    3506 \lstinline$lvalue T$ is a \Index{modifiable lvalue} of type \lstinline$T$.
    3507 \lstinline$const$\use{const} and \lstinline$volatile$\use{volatile} qualifiers may also be added to
    3508 indicate that the function result is a constant or volatile lvalue.
    3509 \begin{rationale}
    3510 The \lstinline$const$ and \lstinline$volatile$ qualifiers can only be sensibly used to qualify the
    3511 return type of a function if the \lstinline$lvalue$ qualifier is also used.
    3512 \end{rationale}
    3513 
    3514 An {lvalue}-qualified type may be used in a \Index{cast expression} if the operand is an lvalue; the
    3515 result of the expression is an lvalue.
    3516 
    3517 \begin{rationale}
    3518 \lstinline$lvalue$ provides some of the functionality of {\CC}'s ``\lstinline$T&$'' ( reference to
    3519 object of type \lstinline$T$) type. Reference types have four uses in {\CC}.
    3520 \begin{itemize}
    3521 \item
    3522 They are necessary for user-defined operators that return lvalues, such as ``subscript'' and
    3523 ``dereference''.
    3524 
    3525 \item
    3526 A reference can be used to define an alias for a complicated lvalue expression, as a way of getting
    3527 some of the functionality of the Pascal \lstinline$with$ statement. The following {\CC} code gives
    3528 an example.
    3529 \begin{lstlisting}
    3530 {
    3531         char &code = long_name.some_field[i].data->code;
    3532         code = toupper( code );
    3533 }
    3534 \end{lstlisting}
    3535 This is not very useful.
    3536 
    3537 \item
    3538 A reference parameter can be used to allow a function to modify an argument without forcing the
    3539 caller to pass the address of the argument. This is most useful for user-defined assignment
    3540 operators. In {\CC}, plain assignment is done by a function called ``\lstinline$operator=$'', and
    3541 the two expressions
    3542 \begin{lstlisting}
    3543 a = b;
    3544 operator=( a, b );
    3545 \end{lstlisting}
    3546 are equivalent. If \lstinline$a$ and \lstinline$b$ are of type \lstinline$T$, then the first
    3547 parameter of \lstinline$operator=$ must have type ``\lstinline$T&$''. It cannot have type
    3548 \lstinline$T$, because then assignment couldn't alter the variable, and it can't have type
    3549 ``\lstinline$T *$'', because the assignment would have to be written ``\lstinline$&a = b;$''.
    3550 
    3551 In the case of user-defined operators, this could just as well be handled by using pointer types and
    3552 by changing the rewrite rules so that ``\lstinline$a = b;$'' is equivalent to
    3553 ``\lstinline$operator=(&( a), b )$''. Reference parameters of ``normal'' functions are Bad Things,
    3554 because they remove a useful property of C function calls: an argument can only be modified by a
    3555 function if it is preceded by ``\lstinline$&$''.
    3556 
    3557 \item
    3558 References to \Index{const-qualified} types can be used instead of value parameters.  Given the
    3559 {\CC} function call ``\lstinline$fiddle( a_thing )$'', where the type of \lstinline$a_thing$ is
    3560 \lstinline$Thing$, the type of \lstinline$fiddle$ could be either of
    3561 \begin{lstlisting}
    3562 void fiddle( Thing );
    3563 void fiddle( const Thing & );
    3564 \end{lstlisting}
    3565 If the second form is used, then constructors and destructors are not invoked to create a temporary
    3566 variable at the call site ( and it is bad style for the caller to make any assumptions about such
    3567 things), and within \lstinline$fiddle$ the parameter is subject to the usual problems caused by
    3568 aliases. The reference form might be chosen for efficiency's sake if \lstinline$Thing$s are too
    3569 large or their constructors or destructors are too expensive. An implementation may switch between
    3570 them without causing trouble for well-behaved clients. This leaves the implementor to define ``too
    3571 large'' and ``too expensive''.
    3572 
    3573 I propose to push this job onto the compiler by allowing it to implement
    3574 \begin{lstlisting}
    3575 void fiddle( const volatile Thing );
    3576 \end{lstlisting}
    3577 with call-by-reference. Since it knows all about the size of \lstinline$Thing$s and the parameter
    3578 passing mechanism, it should be able to come up with a better definition of ``too large'', and may
    3579 be able to make a good guess at ``too expensive''.
    3580 \end{itemize}
    3581 
    3582 In summary, since references are only really necessary for returning lvalues, I'll only provide
    3583 lvalue functions.
    3584 \end{rationale}
    3585 
    3586 
    3587 \setcounter{subsection}{8}
    3588 \subsection{Initialization}
    3589 
    3590 An expression that is used as an \nonterm{initializer} is treated as being cast to the type of the
    3591 object being initialized. An expression used in an \nonterm{initializer-list} is treated as being
    3592 cast to the type of the aggregate member that it initializes. In either case the cast must have a
    3593 single unambiguous \Index{interpretation}.
    3594 
    3595 
    3596 \setcounter{subsection}{10}
    3597 \subsection{Specification definitions}
    3598 
    3599 \begin{syntax}
    3600 \lhs{spec-definition}
    3601 \rhs \lstinline$spec$ \nonterm{identifier}
    3602         \lstinline$($ \nonterm{type-parameter-list} \lstinline$)$
    3603         \lstinline${$ \nonterm{spec-declaration-list}\opt \lstinline$}$
    3604 \lhs{spec-declaration-list}
    3605 \rhs \nonterm{spec-declaration} \lstinline$;$
    3606 \rhs \nonterm{spec-declaration-list} \nonterm{spec-declaration} \lstinline$;$
    3607 \lhs{spec-declaration}
    3608 \rhs \nonterm{specifier-qualifier-list} \nonterm{declarator-list}
    3609 \lhs{declarator-list}
    3610 \rhs \nonterm{declarator}
    3611 \rhs \nonterm{declarator-list} \lstinline$,$ \nonterm{declarator}
    3612 \end{syntax}
    3613 \begin{rationale}
    3614 The declarations allowed in a specification are much the same as those allowed in a structure,
    3615 except that bit fields are not allowed, and \Index{incomplete type}s and function types are allowed.
    3616 \end{rationale}
    3617 
    3618 \semantics
    3619 A \define{specification definition} defines a name for a \define{specification}: a parameterized
    3620 collection of object and function declarations.
    3621 
    3622 The declarations in a specification consist of the declarations in the
    3623 \nonterm{spec-declaration-list} and declarations produced by any assertions in the
    3624 \nonterm{spec-parameter-list}. If the collection contains two declarations that declare the same
    3625 identifier and have compatible types, they are combined into one declaration with the composite type
    3626 constructed from the two types.
    3627 
    3628 
    3629 \subsubsection{Assertions}
    3630 
    3631 \begin{syntax}
    3632 \lhs{assertion-list}
    3633 \rhs \nonterm{assertion}
    3634 \rhs \nonterm{assertion-list} \nonterm{assertion}
    3635 \lhs{assertion}
    3636 \rhs \lstinline$|$ \nonterm{identifier} \lstinline$($ \nonterm{type-name-list} \lstinline$)$
    3637 \rhs \lstinline$|$ \nonterm{spec-declaration}
    3638 \lhs{type-name-list}
    3639 \rhs \nonterm{type-name}
    3640 \rhs \nonterm{type-name-list} \lstinline$,$ \nonterm{type-name}
    3641 \end{syntax}
    3642 
    3643 \constraints
    3644 The \nonterm{identifier} in an assertion that is not a \nonterm{spec-declaration} shall be the name
    3645 of a specification. The \nonterm{type-name-list} shall contain one \nonterm{type-name} argument for
    3646 each \nonterm{type-parameter} in that specification's \nonterm{spec-parameter-list}. If the
    3647 \nonterm{type-parameter} uses type-class \lstinline$type$\use{type}, the argument shall be the type
    3648 name of an \Index{object type}; if it uses \lstinline$dtype$, the argument shall be the type name of
    3649 an object type or an \Index{incomplete type}; and if it uses \lstinline$ftype$, the argument shall
    3650 be the type name of a \Index{function type}.
    3651 
    3652 \semantics
    3653 An \define{assertion} is a declaration of a collection of objects and functions, called
    3654 \define{assertion parameters}.
    3655 
    3656 The assertion parameters produced by an assertion that applies the name of a specification to type
    3657 arguments are found by taking the declarations specified in the specification and treating each of
    3658 the specification's parameters as a synonym for the corresponding \nonterm{type-name} argument.
    3659 
    3660 The collection of assertion parameters produced by the \nonterm{assertion-list} are found by
    3661 combining the declarations produced by each assertion. If the collection contains two declarations
    3662 that declare the same identifier and have compatible types, they are combined into one declaration
    3663 with the \Index{composite type} constructed from the two types.
    3664 
    3665 \examples
    3666 \begin{lstlisting}
    3667 forall( type T | T ?*?( T, T ))@\use{?*?}@
    3668 T square( T val ) {@\impl{square}@
    3669         return val + val;
    3670 }
    3671 
    3672 context summable( type T ) {@\impl{summable}@
    3673         T ?+=?( T *, T );@\use{?+=?}@
    3674         const T 0;@\use{0}@
    3675 };
    3676 context list_of( type List, type Element ) {@\impl{list_of}@
    3677         Element car( List );
    3678         List cdr( List );
    3679         List cons( Element, List );
    3680         List nil;
    3681         int is_nil( List );
    3682 };
    3683 context sum_list( type List, type Element | summable( Element ) | list_of( List, Element ) ) {};
    3684 \end{lstlisting}
    3685 \lstinline$sum_list$ contains seven declarations, which describe a list whose elements can be added
    3686 up. The assertion ``\lstinline$|sum_list( i_list, int )$''\use{sum_list} produces the assertion
    3687 parameters
    3688 \begin{lstlisting}
    3689 int ?+=?( int *, int );
    3690 const int 0;
    3691 int car( i_list );
    3692 i_list cdr( i_list );
    3693 i_list cons( int, i_list );
    3694 i_list nil;
    3695 int is_nil;
    3696 \end{lstlisting}
    3697 
    3698 
    3699 \subsection{Type declarations}
    3700 
    3701 \begin{syntax}
    3702 \lhs{type-parameter-list}
    3703 \rhs \nonterm{type-parameter}
    3704 \rhs \nonterm{type-parameter-list} \lstinline$,$ \nonterm{type-parameter}
    3705 \lhs{type-parameter}
    3706 \rhs \nonterm{type-class} \nonterm{identifier} \nonterm{assertion-list}\opt
    3707 \lhs{type-class}
    3708 \rhs \lstinline$type$
    3709 \rhs \lstinline$dtype$
    3710 \rhs \lstinline$ftype$
    3711 \lhs{type-declaration}
    3712 \rhs \nonterm{storage-class-specifier}\opt \lstinline$type$ \nonterm{type-declarator-list} \verb|;|
    3713 \lhs{type-declarator-list}
    3714 \rhs \nonterm{type-declarator}
    3715 \rhs \nonterm{type-declarator-list} \lstinline$,$ \nonterm{type-declarator}
    3716 \lhs{type-declarator}
    3717 \rhs \nonterm{identifier} \nonterm{assertion-list}\opt \lstinline$=$ \nonterm{type-name}
    3718 \rhs \nonterm{identifier} \nonterm{assertion-list}\opt
    3719 \end{syntax}
    3720 
    3721 \constraints
    3722 If a type declaration has block scope, and the declared identifier has external or internal linkage,
    3723 the declaration shall have no initializer for the identifier.
    3724 
    3725 \semantics
    3726 A \nonterm{type-parameter} or a \nonterm{type-declarator} declares an identifier to be a \Index{type
    3727 name} for a type incompatible with all other types.
    3728 
    3729 An identifier declared by a \nonterm{type-parameter} has \Index{no linkage}. Identifiers declared
    3730 with type-class \lstinline$type$\use{type} are \Index{object type}s; those declared with type-class
    3731 \lstinline$dtype$\use{dtype} are \Index{incomplete type}s; and those declared with type-class
    3732 \lstinline$ftype$\use{ftype} are \Index{function type}s. The identifier has \Index{block scope} that
    3733 terminates at the end of the \nonterm{spec-declaration-list} or polymorphic function that contains
    3734 the \nonterm{type-parameter}.
    3735 
    3736 A \nonterm{type-declarator} with an \Index{initializer} is a \define{type definition}.  The declared
    3737 identifier is an \Index{incomplete type} within the initializer, and an \Index{object type} after
    3738 the end of the initializer. The type in the initializer is called the \define{implementation
    3739   type}. Within the scope of the declaration, \Index{implicit conversion}s can be performed between
    3740 the defined type and the implementation type, and between pointers to the defined type and pointers
    3741 to the implementation type.
    3742 
    3743 A type declaration without an \Index{initializer} and without a \Index{storage-class specifier} or
    3744 with storage-class specifier \lstinline$static$\use{static} defines an \Index{incomplete type}. If a
    3745 \Index{translation unit} or \Index{block} contains one or more such declarations for an identifier,
    3746 it must contain exactly one definition of the identifier ( but not in an enclosed block, which would
    3747 define a new type known only within that block).
    3748 \begin{rationale}
    3749 Incomplete type declarations allow compact mutually-recursive types.
    3750 \begin{lstlisting}
    3751 type t1; // Incomplete type declaration.
    3752 type t2 = struct { t1 * p; ... };
    3753 type t1 = struct { t2 * p; ... };
    3754 \end{lstlisting}
    3755 Without them, mutual recursion could be handled by declaring mutually recursive structures, then
    3756 initializing the types to those structures.
    3757 \begin{lstlisting}
    3758 struct s1;
    3759 type t2 = struct s2 { struct s1 * p; ... };
    3760 type t1 = struct s1 { struct s2 * p; ... };
    3761 \end{lstlisting}
    3762 This introduces extra names, and may force the programmer to cast between the types and their
    3763 implementations.
    3764 \end{rationale}
    3765 
    3766 A type declaration without an initializer and with \Index{storage-class specifier}
    3767 \lstinline$extern$\use{extern} is an \define{opaque type declaration}. Opaque types are
    3768 \Index{object type}s. An opaque type is not a \nonterm{constant-expression}; neither is a structure
    3769 or union that has a member whose type is not a \nonterm{constant-expression}.  Every other
    3770 \Index{object type} is a \nonterm{constant-expression}. Objects with static storage duration shall
    3771 be declared with a type that is a \nonterm{constant-expression}.
    3772 \begin{rationale}
    3773 Type declarations can declare identifiers with external linkage, whereas typedef declarations
    3774 declare identifiers that only exist within a translation unit. These opaque types can be used in
    3775 declarations, but the implementation of the type is not visible.
    3776 
    3777 Static objects can not have opaque types because space for them would have to be allocated at
    3778 program start-up. This is a deficiency\index{deficiencies!static opaque objects}, but I don't want
    3779 to deal with ``module initialization'' code just now.
    3780 \end{rationale}
    3781 
    3782 An \Index{incomplete type} which is not a qualified version\index{qualified type} of a type is a
    3783 value of \Index{type-class} \lstinline$dtype$. An object type\index{object types} which is not a
    3784 qualified version of a type is a value of type-classes \lstinline$type$ and \lstinline$dtype$. A
    3785 \Index{function type} is a value of type-class \lstinline$ftype$.
    3786 \begin{rationale}
    3787 Syntactically, a type value is a \nonterm{type-name}, which is a declaration for an object which
    3788 omits the identifier being declared.
    3789 
    3790 Object types are precisely the types that can be instantiated. Type qualifiers are not included in
    3791 type values because the compiler needs the information they provide at compile time to detect
    3792 illegal statements or to produce efficient machine instructions. For instance, the code that a
    3793 compiler must generate to manipulate an object that has volatile-qualified type may be different
    3794 from the code to manipulate an ordinary object.
    3795 
    3796 Type qualifiers are a weak point of C's type system. Consider the standard library function
    3797 \lstinline$strchr()$ which, given a string and a character, returns a pointer to the first
    3798 occurrence of the character in the string.
    3799 \begin{lstlisting}
    3800 char *strchr( const char *s, int c ) {@\impl{strchr}@
    3801         char real_c = c; // done because c was declared as int.
    3802         for ( ; *s != real_c; s++ )
    3803          if ( *s == '\0' ) return NULL;
    3804         return ( char * )s;
    3805 }
    3806 \end{lstlisting}
    3807 The parameter \lstinline$s$ must be \lstinline$const char *$, because \lstinline$strchr()$ might be
    3808 used to search a constant string, but the return type must be \lstinline$char *$, because the result
    3809 might be used to modify a non-constant string. Hence the body must perform a cast, and ( even worse)
    3810 \lstinline$strchr()$ provides a type-safe way to attempt to modify constant strings. What is needed
    3811 is some way to say that \lstinline$s$'s type might contain qualifiers, and the result type has
    3812 exactly the same qualifiers. Polymorphic functions do not provide a fix for this
    3813 deficiency\index{deficiencies!pointers to qualified types}, because type qualifiers are not part of
    3814 type values. Instead, overloading can be used to define \lstinline$strchr()$ for each combination
    3815 of qualifiers.
    3816 \end{rationale}
    3817 
    3818 \begin{rationale}
    3819 Since \Index{incomplete type}s are not type values, they can not be used as the initializer in a
    3820 type declaration, or as the type of a structure or union member. This prevents the declaration of
    3821 types that contain each other.
    3822 \begin{lstlisting}
    3823 type t1;
    3824 type t2 = t1; // illegal: incomplete type t1.
    3825 type t1 = t2;
    3826 \end{lstlisting}
    3827 
    3828 The initializer in a file-scope declaration must be a constant expression. This means type
    3829 declarations can not build on opaque types, which is a deficiency\index{deficiencies!nesting opaque
    3830  types}.
    3831 \begin{lstlisting}
    3832 extern type Huge; // extended-precision integer type.
    3833 type Rational = struct {
    3834         Huge numerator, denominator;    // illegal
    3835 };
    3836 struct Pair {
    3837         Huge first, second;                             // legal
    3838 };
    3839 \end{lstlisting}
    3840 Without this restriction, \CFA might require ``module initialization'' code ( since
    3841 \lstinline$Rational$ has external linkage, it must be created before any other translation unit
    3842 instantiates it), and would force an ordering on the initialization of the translation unit that
    3843 defines \lstinline$Huge$ and the translation that declares \lstinline$Rational$.
    3844 
    3845 A benefit of the restriction is that it prevents the declaration in separate translation units of
    3846 types that contain each other, which would be hard to prevent otherwise.
    3847 \begin{lstlisting}
    3848 //  File a.c:
    3849         extern type t1;
    3850         type t2 = struct { t1 f1; ... } // illegal
    3851 //  File b.c:
    3852         extern type t2;
    3853         type t1 = struct { t2 f2; ... } // illegal
    3854 \end{lstlisting}
    3855 \end{rationale}
    3856 
    3857 \begin{rationale}
    3858 Since a \nonterm{type-declaration} is a \nonterm{declaration} and not a
    3859 \nonterm{struct-declaration}, type declarations can not be structure members. The form of
    3860 \nonterm{type-declaration} forbids arrays of, pointers to, and functions returning \lstinline$type$.
    3861 Hence the syntax of \nonterm{type-specifier} does not have to be extended to allow type-valued
    3862 expressions. It also side-steps the problem of type-valued expressions producing different values
    3863 in different declarations.
    3864 
    3865 Since a type declaration is not a \nonterm{parameter-declaration}, functions can not have explicit
    3866 type parameters. This may be too restrictive, but it attempts to make compilation simpler. Recall
    3867 that when traditional C scanners read in an identifier, they look it up in the symbol table to
    3868 determine whether or not it is a typedef name, and return a ``type'' or ``identifier'' token
    3869 depending on what they find. A type parameter would add a type name to the current scope. The
    3870 scope manipulations involved in parsing the declaration of a function that takes function pointer
    3871 parameters and returns a function pointer may just be too complicated.
    3872 
    3873 Explicit type parameters don't seem to be very useful, anyway, because their scope would not include
    3874 the return type of the function. Consider the following attempt to define a type-safe memory
    3875 allocation function.
    3876 \begin{lstlisting}
    3877 #include <stdlib.h>
    3878 T * new( type T ) { return ( T * )malloc( sizeof( T) ); };
    3879 @\ldots@
    3880 int * ip = new( int );
    3881 \end{lstlisting}
    3882 This looks sensible, but \CFA's declaration-before-use rules mean that ``\lstinline$T$'' in the
    3883 function body refers to the parameter, but the ``\lstinline$T$'' in the return type refers to the
    3884 meaning of \lstinline$T$ in the scope that contains \lstinline$new$; it could be undefined, or a
    3885 type name, or a function or variable name. Nothing good can result from such a situation.
    3886 \end{rationale}
    3887 
    3888 \examples
    3889 Since type declarations create new types, instances of types are always passed by value.
    3890 \begin{lstlisting}
    3891 type A1 = int[2];
    3892 void f1( A1 a ) { a[0] = 0; };
    3893 typedef int A2[2];
    3894 void f2( A2 a ) { a[0] = 0; };
    3895 A1 v1;
    3896 A2 v2;
    3897 f1( v1 );
    3898 f2( v2 );
    3899 \end{lstlisting}
    3900 \lstinline$V1$ is passed by value, so \lstinline$f1()$'s assignment to \lstinline$a[0]$ does not
    3901 modify v1.  \lstinline$V2$ is converted to a pointer, so \lstinline$f2()$ modifies
    3902 \lstinline$v2[0]$.
    3903 
    3904 A translation unit containing the declarations
    3905 \begin{lstlisting}
    3906 extern type Complex;@\use{Complex}@ // opaque type declaration.
    3907 extern float abs( Complex );@\use{abs}@
    3908 \end{lstlisting}
    3909 can contain declarations of complex numbers, which can be passed to \lstinline$abs$. Some other
    3910 translation unit must implement \lstinline$Complex$ and \lstinline$abs$. That unit might contain
    3911 the declarations
    3912 \begin{lstlisting}
    3913 type Complex = struct { float re, im; };@\impl{Complex}@
    3914 Complex cplx_i = { 0.0, 1.0 };@\impl{cplx_i}@
    3915 float abs( Complex c ) {@\impl{abs( Complex )}@
    3916         return sqrt( c.re * c.re + c.im * c.im );
    3917 }
    3918 \end{lstlisting}
    3919 Note that \lstinline$c$ is implicitly converted to a \lstinline$struct$ so that its components can
    3920 be retrieved.
    3921 
    3922 \begin{lstlisting}
    3923 type Time_of_day = int;@\impl{Time_of_day}@ // seconds since midnight.
    3924 Time_of_day ?+?( Time_of_day t1, int seconds ) {@\impl{?+?}@
    3925         return (( int)t1 + seconds ) % 86400;
    3926 }
    3927 \end{lstlisting}
    3928 \lstinline$t1$ must be cast to its implementation type to prevent infinite recursion.
    3929 
    3930 \begin{rationale}
    3931 Within the scope of a type definition, an instance of the type can be viewed as having that type or
    3932 as having the implementation type. In the \lstinline$Time_of_day$ example, the difference is
    3933 important. Different languages have treated the distinction between the abstraction and the
    3934 implementation in different ways.
    3935 \begin{itemize}
    3936 \item
    3937 Inside a Clu cluster \cite{clu}, the declaration of an instance states which view applies. Two
    3938 primitives called \lstinline$up$ and \lstinline$down$ can be used to convert between the views.
    3939 \item
    3940 The Simula class \cite{Simula87} is essentially a record type. Since the only operations on a
    3941 record are member selection and assignment, which can not be overloaded, there is never any
    3942 ambiguity as to whether the abstraction or the implementation view is being used. In {\CC}
    3943 \cite{c++}, operations on class instances include assignment and ``\lstinline$&$'', which can be
    3944 overloaded. A ``scope resolution'' operator can be used inside the class to specify whether the
    3945 abstract or implementation version of the operation should be used.
    3946 \item
    3947 An Ada derived type definition \cite{ada} creates a new type from an old type, and also implicitly
    3948 declares derived subprograms that correspond to the existing subprograms that use the old type as a
    3949 parameter type or result type. The derived subprograms are clones of the existing subprograms with
    3950 the old type replaced by the derived type. Literals and aggregates of the old type are also cloned.
    3951 In other words, the abstract view provides exactly the same operations as the implementation view.
    3952 This allows the abstract view to be used in all cases.
    3953 
    3954 The derived subprograms can be replaced by programmer-specified subprograms. This is an exception
    3955 to the normal scope rules, which forbid duplicate definitions of a subprogram in a scope. In this
    3956 case, explicit conversions between the derived type and the old type can be used.
    3957 \end{itemize}
    3958 \CFA's rules are like Clu's, except that implicit conversions and
    3959 conversion costs allow it to do away with most uses of \lstinline$up$ and \lstinline$down$.
    3960 \end{rationale}
    3961 
    3962 
    3963 \subsubsection{Default functions and objects}
    3964 
    3965 A declaration\index{type declaration} of a type identifier \lstinline$T$ with type-class
    3966 \lstinline$type$ implicitly declares a \define{default assignment} function
    3967 \lstinline$T ?=?( T *, T )$\use{?=?}, with the same \Index{scope} and \Index{linkage} as the
    3968 identifier \lstinline$T$.
    3969 \begin{rationale}
    3970 Assignment is central to C's imperative programming style, and every existing C object type has
    3971 assignment defined for it ( except for array types, which are treated as pointer types for purposes
    3972 of assignment). Without this rule, nearly every inferred type parameter would need an accompanying
    3973 assignment assertion parameter. If a type parameter should not have an assignment operation,
    3974 \lstinline$dtype$ should be used. If a type should not have assignment defined, the user can define
    3975 an assignment function that causes a run-time error, or provide an external declaration but no
    3976 definition and thus cause a link-time error.
    3977 \end{rationale}
    3978 
    3979 A definition\index{type definition} of a type identifier \lstinline$T$ with \Index{implementation
    3980 type} \lstinline$I$ and type-class \lstinline$type$ implicitly defines a default assignment
    3981 function. A definition\index{type definition} of a type identifier \lstinline$T$ with implementation
    3982 type \lstinline$I$ and an assertion list implicitly defines \define{default function}s and
    3983 \define{default object}s as declared by the assertion declarations. The default objects and
    3984 functions have the same \Index{scope} and \Index{linkage} as the identifier \lstinline$T$. Their
    3985 values are determined as follows:
    3986 \begin{itemize}
    3987 \item
    3988 If at the definition of \lstinline$T$ there is visible a declaration of an object with the same name
    3989 as the default object, and if the type of that object with all occurrence of \lstinline$I$ replaced
    3990 by \lstinline$T$ is compatible with the type of the default object, then the default object is
    3991 initialized with that object. Otherwise the scope of the declaration of \lstinline$T$ must contain
    3992 a definition of the default object.
    3993 
    3994 \item
    3995 If at the definition of \lstinline$T$ there is visible a declaration of a function with the same
    3996 name as the default function, and if the type of that function with all occurrence of \lstinline$I$
    3997 replaced by \lstinline$T$ is compatible with the type of the default function, then the default
    3998 function calls that function after converting its arguments and returns the converted result.
    3999 
    4000 Otherwise, if \lstinline$I$ contains exactly one anonymous member\index{anonymous member} such that
    4001 at the definition of \lstinline$T$ there is visible a declaration of a function with the same name
    4002 as the default function, and the type of that function with all occurrences of the anonymous
    4003 member's type in its parameter list replaced by \lstinline$T$ is compatible with the type of the
    4004 default function, then the default function calls that function after converting its arguments and
    4005 returns the result.
    4006 
    4007 Otherwise the scope of the declaration of \lstinline$T$ must contain a definition of the default
    4008 function.
    4009 \end{itemize}
    4010 \begin{rationale}
    4011 Note that a pointer to a default function will not compare as equal to a pointer to the inherited
    4012 function.
    4013 \end{rationale}
    4014 
    4015 A function or object with the same type and name as a default function or object that is declared
    4016 within the scope of the definition of \lstinline$T$ replaces the default function or object.
    4017 
    4018 \examples
    4019 \begin{lstlisting}
    4020 context s( type T ) {
    4021         T a, b;
    4022 }
    4023 struct impl { int left, right; } a = { 0, 0 };
    4024 type Pair | s( Pair ) = struct impl;
    4025 Pair b = { 1, 1 };
    4026 \end{lstlisting}
    4027 The definition of \lstinline$Pair$ implicitly defines two objects \lstinline$a$ and \lstinline$b$.
    4028 \lstinline$Pair a$ inherits its value from the \lstinline$struct impl a$. The definition of
    4029 \lstinline$Pair b$ is compulsory because there is no \lstinline$struct impl b$ to construct a value
    4030 from.
    4031 \begin{lstlisting}
    4032 context ss( type T ) {
    4033         T clone( T );
    4034         void munge( T * );
    4035 }
    4036 type Whatsit | ss( Whatsit );@\use{Whatsit}@
    4037 type Doodad | ss( Doodad ) = struct doodad {@\use{Doodad}@
    4038         Whatsit; // anonymous member
    4039         int extra;
    4040 };
    4041 Doodad clone( Doodad ) { ... }
    4042 \end{lstlisting}
    4043 The definition of \lstinline$Doodad$ implicitly defines three functions:
    4044 \begin{lstlisting}
    4045 Doodad ?=?( Doodad *, Doodad );
    4046 Doodad clone( Doodad );
    4047 void munge( Doodad * );
    4048 \end{lstlisting}
    4049 The assignment function inherits \lstinline$struct doodad$'s assignment function because the types
    4050 match when \lstinline$struct doodad$ is replaced by \lstinline$Doodad$ throughout.
    4051 \lstinline$munge()$ inherits \lstinline$Whatsit$'s \lstinline$munge()$ because the types match when
    4052 \lstinline$Whatsit$ is replaced by \lstinline$Doodad$ in the parameter list. \lstinline$clone()$
    4053 does \emph{not} inherit \lstinline$Whatsit$'s \lstinline$clone()$: replacement in the parameter
    4054 list yields ``\lstinline$Whatsit clone( Doodad )$'', which is not compatible with
    4055 \lstinline$Doodad$'s \lstinline$clone()$'s type. Hence the definition of
    4056 ``\lstinline$Doodad clone( Doodad )$'' is necessary.
    4057 
    4058 Default functions and objects are subject to the normal scope rules.
    4059 \begin{lstlisting}
    4060 type T = @\ldots@;
    4061 T a_T = @\ldots@;               // Default assignment used.
    4062 T ?=?( T *, T );
    4063 T a_T = @\ldots@;               // Programmer-defined assignment called.
    4064 \end{lstlisting}
    4065 \begin{rationale}
    4066 A compiler warning would be helpful in this situation.
    4067 \end{rationale}
    4068 
    4069 \begin{rationale}
    4070 The \emph{class} construct of object-oriented programming languages performs three independent
    4071 functions. It \emph{encapsulates} a data structure; it defines a \emph{subtype} relationship, whereby
    4072 instances of one class may be used in contexts that require instances of another; and it allows one
    4073 class to \emph{inherit} the implementation of another.
    4074 
    4075 In \CFA, encapsulation is provided by opaque types and the scope rules, and subtyping is provided
    4076 by specifications and assertions. Inheritance is provided by default functions and objects.
    4077 \end{rationale}
    4078 
    4079 
    4080 \section{Statements and blocks}
    4081 
    4082 \begin{syntax}
    4083 \oldlhs{statement}
    4084 \rhs \nonterm{exception-statement}
    4085 \end{syntax}
    4086 
    4087 Many statements contain expressions, which may have more than one interpretation. The following
    4088 sections describe how the \CFA translator selects an interpretation. In all cases the result of the
    4089 selection shall be a single unambiguous \Index{interpretation}.
    4090 
    4091 
    4092 \subsection{Labeled statements}
    4093 
    4094 \begin{syntax}
    4095 \oldlhs{labeled-statement}
    4096 \rhs \lstinline$case$ \nonterm{case-value-list} : \nonterm{statement}
    4097 \lhs{case-value-list}
    4098 \rhs \nonterm{case-value}
    4099 \rhs \nonterm{case-value-list} \lstinline$,$ \nonterm{case-value}
    4100 \lhs{case-value}
    4101 \rhs \nonterm{constant-expression}
    4102 \rhs \nonterm{subrange}
    4103 \lhs{subrange}
    4104 \rhs \nonterm{constant-expression} \lstinline$~$ \nonterm{constant-expression}
    4105 \end{syntax}
    4106 
    4107 The following have identical meaning:
    4108 \begin{lstlisting}
    4109 case 1:  case 2:  case 3:  case 4:  case 5:
    4110 case 1, 2, 3, 4, 5:
    4111 case 1~5:
    4112 \end{lstlisting}
    4113 Multiple subranges are allowed:
    4114 \begin{lstlisting}
    4115 case 1~4, 9~14, 27~32:
    4116 \end{lstlisting}
    4117 The \lstinline$case$ and \lstinline$default$ clauses are restricted within the \lstinline$switch$ and \lstinline$choose$ statements, precluding Duff's device.
    4118 
    4119 
    4120 \subsection{Expression and null statements}
    4121 
    4122 The expression in an expression statement is treated as being cast to \lstinline$void$.
    4123 
    4124 
    4125 \subsection{Selection statements}
    4126 
    4127 \begin{syntax}
    4128 \oldlhs{selection-statement}
    4129 \rhs \lstinline$choose$ \lstinline$($ \nonterm{expression} \lstinline$)$ \nonterm{statement}
    4130 \end{syntax}
    4131 
    4132 The controlling expression \lstinline$E$ in the \lstinline$switch$ and \lstinline$choose$ statement:
    4133 \begin{lstlisting}
    4134 switch ( E ) ...
    4135 choose ( E ) ...
    4136 \end{lstlisting}
    4137 may have more than one interpretation, but it shall have only one interpretation with an integral type.
    4138 An \Index{integer promotion} is performed on the expression if necessary.
    4139 The constant expressions in \lstinline$case$ statements with the switch are converted to the promoted type.
    4140 
    4141 
    4142 \setcounter{subsubsection}{3}
    4143 \subsubsection{The \lstinline$choose$ statement}
    4144 
    4145 The \lstinline$choose$ statement is the same as the \lstinline$switch$ statement except control transfers to the end of the \lstinline$choose$ statement at a \lstinline$case$ or \lstinline$default$ labeled statement.
    4146 The \lstinline$fallthru$ statement is used to fall through to the next \lstinline$case$ or \lstinline$default$ labeled statement.
    4147 The following have identical meaning:
    4148 \begin{flushleft}
    4149 \begin{tabular}{@{\hspace{2em}}l@{\hspace{2em}}l@{}}
    4150 \begin{lstlisting}
    4151 switch (...) {
    4152   case 1: ... ; break;
    4153   case 2: ... ; break;
    4154   case 3: ... ; // fall through
    4155   case 4: ... ; // fall through
    4156   default: ... break;
    4157 }
    4158 \end{lstlisting}
    4159 &
    4160 \begin{lstlisting}
    4161 choose (...) {
    4162   case 1: ... ; // exit
    4163   case 2: ... ; // exit
    4164   case 3: ... ; fallthru;
    4165   case 4: ... ; fallthru;
    4166   default: ... ; // exit
    4167 }
    4168 \end{lstlisting}
    4169 \end{tabular}
    4170 \end{flushleft}
    4171 The \lstinline$choose$ statement addresses the problem of accidental fall-through associated with the \lstinline$switch$ statement.
    4172 
    4173 
    4174 \subsection{Iteration statements}
    4175 
    4176 The controlling expression \lstinline$E$ in the loops
    4177 \begin{lstlisting}
    4178 if ( E ) ...
    4179 while ( E ) ...
    4180 do ... while ( E );
    4181 \end{lstlisting}
    4182 is treated as ``\lstinline$( int )((E)!=0)$''.
    4183 
    4184 The statement
    4185 \begin{lstlisting}
    4186 for ( a; b; c ) @\ldots@
    4187 \end{lstlisting}
    4188 is treated as
    4189 \begin{lstlisting}
    4190 for ( ( void )( a ); ( int )(( b )!=0); ( void )( c ) ) ...
    4191 \end{lstlisting}
    4192 
    4193 
    4194 \subsection{Jump statements}
    4195 
    4196 \begin{syntax}
    4197 \oldlhs{jump-statement}
    4198 \rhs \lstinline$continue$ \nonterm{identifier}\opt
    4199 \rhs \lstinline$break$ \nonterm{identifier}\opt
    4200 \rhs \ldots
    4201 \rhs \lstinline$throw$ \nonterm{assignment-expression}\opt
    4202 \rhs \lstinline$throwResume$ \nonterm{assignment-expression}\opt \nonterm{at-expression}\opt
    4203 \lhs{at-expression} \lstinline$_At$ \nonterm{assignment-expression}
    4204 \end{syntax}
    4205 
    4206 Labeled \lstinline$continue$ and \lstinline$break$ allow useful but restricted control-flow that reduces the need for the \lstinline$goto$ statement for exiting multiple nested control-structures.
    4207 \begin{lstlisting}
    4208 L1: {                                                   // compound
    4209   L2: switch ( ... ) {                  // switch
    4210           case ...:
    4211           L3: for ( ;; ) {                      // outer for
    4212                 L4: for ( ;; ) {                // inner for
    4213                                 continue L1;    // error: not enclosing iteration
    4214                                 continue L2;    // error: not enclosing iteration
    4215                                 continue L3;    // next iteration of outer for
    4216                                 continue L4;    // next iteration of inner for
    4217                                 break L1;               // exit compound
    4218                                 break L2;               // exit switch
    4219                                 break L3;               // exit outer for
    4220                                 break L4;               // exit inner for
    4221                         } // for
    4222                 } // for
    4223                 break;                                  // exit switch
    4224           default:
    4225                 break L1;                               // exit compound
    4226         } // switch
    4227         ...
    4228 } // compound
    4229 \end{lstlisting}
    4230 
    4231 
    4232 \setcounter{subsubsection}{1}
    4233 \subsubsection{The \lstinline$continue$ statement}
    4234 
    4235 The identifier in a \lstinline$continue$ statement shall name a label located on an enclosing iteration statement.
    4236 
    4237 
    4238 \subsubsection{The \lstinline$break$ statement}
    4239 
    4240 The identifier in a \lstinline$break$ statement shall name a label located on an enclosing compound, selection or iteration statement.
    4241 
    4242 
    4243 \subsubsection{The \lstinline$return$ statement}
    4244 
    4245 An expression in a \lstinline$return$ statement is treated as being cast to the result type of the function.
    4246 
    4247 
    4248 \subsubsection{The \lstinline$throw$ statement}
    4249 
    4250 When an exception is raised, \Index{propagation} directs control from a raise in the source execution to a handler in the faulting execution.
    4251 
    4252 
    4253 \subsubsection{The \lstinline$throwResume$ statement}
    4254 
    4255 
    4256 \subsection{Exception statements}
    4257 
    4258 \begin{syntax}
    4259 \lhs{exception-statement}
    4260 \rhs \lstinline$try$ \nonterm{compound-statement} \nonterm{handler-list}
    4261 \rhs \lstinline$try$ \nonterm{compound-statement} \nonterm{finally-clause}
    4262 \rhs \lstinline$try$ \nonterm{compound-statement} \nonterm{handler-list} \nonterm{finally-clause}
    4263 \lhs{handler-list}
    4264 \rhs \nonterm{handler-clause}
    4265 \rhs \lstinline$catch$ \lstinline$($ \ldots \lstinline$)$ \nonterm{compound-statement}
    4266 \rhs \nonterm{handler-clause} \lstinline$catch$ \lstinline$($ \ldots \lstinline$)$ \nonterm{compound-statement}
    4267 \rhs \lstinline$catchResume$ \lstinline$($ \ldots \lstinline$)$ \nonterm{compound-statement}
    4268 \rhs \nonterm{handler-clause} \lstinline$catchResume$ \lstinline$($ \ldots \lstinline$)$ \nonterm{compound-statement}
    4269 \lhs{handler-clause}
    4270 \rhs \lstinline$catch$ \lstinline$($ \nonterm{exception-declaration} \lstinline$)$ \nonterm{compound-statement}
    4271 \rhs \nonterm{handler-clause} \lstinline$catch$ \lstinline$($ \nonterm{exception-declaration} \lstinline$)$ \nonterm{compound-statement}
    4272 \rhs \lstinline$catchResume$ \lstinline$($ \nonterm{exception-declaration} \lstinline$)$ \nonterm{compound-statement}
    4273 \rhs \nonterm{handler-clause} \lstinline$catchResume$ \lstinline$($ \nonterm{exception-declaration} \lstinline$)$ \nonterm{compound-statement}
    4274 \lhs{finally-clause}
    4275 \rhs \lstinline$finally$ \nonterm{compound-statement}
    4276 \lhs{exception-declaration}
    4277 \rhs \nonterm{type-specifier}
    4278 \rhs \nonterm{type-specifier} \nonterm{declarator}
    4279 \rhs \nonterm{type-specifier} \nonterm{abstract-declarator}
    4280 \rhs \nonterm{new-abstract-declarator-tuple} \nonterm{identifier}
    4281 \rhs \nonterm{new-abstract-declarator-tuple}
    4282 \lhs{asynchronous-statement}
    4283 \rhs \lstinline$enable$ \nonterm{identifier-list} \nonterm{compound-statement}
    4284 \rhs \lstinline$disable$ \nonterm{identifier-list} \nonterm{compound-statement}
    4285 \end{syntax}
    4286 
    4287 \Index{Exception statement}s allow a dynamic call to a handler for \Index{recovery} (\Index{termination}) or \Index{correction} (\Index{resumption}) of an \Index{abnormal event}.
    4288 
    4289 
    4290 \subsubsection{The \lstinline$try$ statement}
    4291 
    4292 The \lstinline$try$ statement is a block with associated handlers, called a \Index{guarded block};
    4293 all other blocks are \Index{unguarded block}s.
    4294 A \lstinline$goto$, \lstinline$break$, \lstinline$return$, or \lstinline$continue$ statement can be used to transfer control out of a try block or handler, but not into one.
    4295 
    4296 
    4297 \subsubsection{The \lstinline$enable$/\lstinline$disable$ statements}
    4298 
    4299 The \lstinline$enable$/\lstinline$disable$ statements toggle delivery of \Index{asynchronous exception}s.
    4300 
    4301 
    4302 \setcounter{section}{9}
    4303 \section{Preprocessing directives}
    4304 
    4305 
    4306 \setcounter{subsection}{7}
    4307 \subsection{Predefined macro names}
    4308 
    4309 The implementation shall define the macro names \lstinline$__LINE__$, \lstinline$__FILE__$,
    4310 \lstinline$__DATE__$, and \lstinline$__TIME__$, as in the {\c11} standard. It shall not define the
    4311 macro name \lstinline$__STDC__$.
    4312 
    4313 In addition, the implementation shall define the macro name \lstinline$__CFORALL__$ to be the
    4314 decimal constant 1.
    4315 
    4316 
    4317 \appendix
    4318 
    4319 
    4320 \chapter{Examples}
    4321 
    4322 
    4323 \section{C types}
    4324 This section gives example specifications for some groups of types that are important in the C
    4325 language, in terms of the predefined operations that can be applied to those types.
    4326 
    4327 
    4328 \subsection{Scalar, arithmetic, and integral types}
    4329 
    4330 The pointer, integral, and floating-point types are all \define{scalar types}. All of these types
    4331 can be logically negated and compared. The assertion ``\lstinline$scalar( Complex )$'' should be read
    4332 as ``type \lstinline$Complex$ is scalar''.
    4333 \begin{lstlisting}
    4334 context scalar( type T ) {@\impl{scalar}@
    4335         int !?( T );
    4336         int ?<?( T, T ), ?<=?( T, T ), ?==?( T, T ), ?>=?( T, T ), ?>?( T, T ), ?!=?( T, T );
    4337 };
    4338 \end{lstlisting}
    4339 
    4340 The integral and floating-point types are \define{arithmetic types}, which support the basic
    4341 arithmetic operators. The use of an assertion in the \nonterm{spec-parameter-list} declares that,
    4342 in order to be arithmetic, a type must also be scalar ( and hence that scalar operations are
    4343 available ). This is equivalent to inheritance of specifications.
    4344 \begin{lstlisting}
    4345 context arithmetic( type T | scalar( T ) ) {@\impl{arithmetic}@@\use{scalar}@
    4346         T +?( T ), -?( T );
    4347         T ?*?( T, T ), ?/?( T, T ), ?+?( T, T ), ?-?( T, T );
    4348 };
    4349 \end{lstlisting}
    4350 
    4351 The various flavors of \lstinline$char$ and \lstinline$int$ and the enumerated types make up the
    4352 \define{integral types}.
    4353 \begin{lstlisting}
    4354 context integral( type T | arithmetic( T ) ) {@\impl{integral}@@\use{arithmetic}@
    4355         T ~?( T );
    4356         T ?&?( T, T ), ?|?( T, T ), ?^?( T, T );
    4357         T ?%?( T, T );
    4358         T ?<<?( T, T ), ?>>?( T, T );
    4359 };
    4360 \end{lstlisting}
    4361 
    4362 
    4363 \subsection{Modifiable types}
    4364 \index{modifiable lvalue}
    4365 
    4366 The only operation that can be applied to all modifiable lvalues is simple assignment.
    4367 \begin{lstlisting}
    4368 context m_lvalue( type T ) {@\impl{m_lvalue}@
    4369         T ?=?( T *, T );
    4370 };
    4371 \end{lstlisting}
    4372 
    4373 Modifiable scalar lvalues are scalars and are modifiable lvalues, and assertions in the
    4374 \nonterm{spec-parameter-list} reflect those relationships. This is equivalent to multiple
    4375 inheritance of specifications. Scalars can also be incremented and decremented.
    4376 \begin{lstlisting}
    4377 context m_l_scalar( type T | scalar( T ) | m_lvalue( T ) ) {@\impl{m_l_scalar}@
    4378         T ?++( T * ), ?--( T * );@\use{scalar}@@\use{m_lvalue}@
    4379         T ++?( T * ), --?( T * );
    4380 };
    4381 \end{lstlisting}
    4382 
    4383 Modifiable arithmetic lvalues are both modifiable scalar lvalues and arithmetic. Note that this
    4384 results in the ``inheritance'' of \lstinline$scalar$ along both paths.
    4385 \begin{lstlisting}
    4386 context m_l_arithmetic( type T | m_l_scalar( T ) | arithmetic( T ) ) {@\impl{m_l_arithmetic}@
    4387         T ?/=?( T *, T ), ?*=?( T *, T );@\use{m_l_scalar}@@\use{arithmetic}@
    4388         T ?+=?( T *, T ), ?-=?( T *, T );
    4389 };
    4390 
    4391 context m_l_integral( type T | m_l_arithmetic( T ) | integral( T ) ) {@\impl{m_l_integral}@
    4392         T ?&=?( T *, T ), ?|=?( T *, T ), ?^=?( T *, T );@\use{m_l_arithmetic}@
    4393         T ?%=?( T *, T ), ?<<=?( T *, T ), ?>>=?( T *, T );@\use{integral}@
    4394 };
    4395 \end{lstlisting}
    4396 
    4397 
    4398 \subsection{Pointer and array types}
    4399 
    4400 Array types can barely be said to exist in {\c11}, since in most cases an array name is treated as a
    4401 constant pointer to the first element of the array, and the subscript expression
    4402 ``\lstinline$a[i]$'' is equivalent to the dereferencing expression ``\lstinline$(*( a+( i )))$''.
    4403 Technically, pointer arithmetic and pointer comparisons other than ``\lstinline$==$'' and
    4404 ``\lstinline$!=$'' are only defined for pointers to array elements, but the type system does not
    4405 enforce those restrictions. Consequently, there is no need for a separate ``array type''
    4406 specification.
    4407 
    4408 Pointer types are scalar types. Like other scalar types, they have ``\lstinline$+$'' and
    4409 ``\lstinline$-$'' operators, but the types do not match the types of the operations in
    4410 \lstinline$arithmetic$, so these operators cannot be consolidated in \lstinline$scalar$.
    4411 \begin{lstlisting}
    4412 context pointer( type P | scalar( P ) ) {@\impl{pointer}@@\use{scalar}@
    4413         P ?+?( P, long int ), ?+?( long int, P ), ?-?( P, long int );
    4414         ptrdiff_t ?-?( P, P );
    4415 };
    4416 
    4417 context m_l_pointer( type P | pointer( P ) | m_l_scalar( P ) ) {@\impl{m_l_pointer}@
    4418         P ?+=?( P *, long int ), ?-=?( P *, long int );
    4419         P ?=?( P *, void * );
    4420         void * ?=?( void **, P );
    4421 };
    4422 \end{lstlisting}
    4423 
    4424 Specifications that define the dereference operator ( or subscript operator ) require two
    4425 parameters, one for the pointer type and one for the pointed-at ( or element ) type. Different
    4426 specifications are needed for each set of \Index{type qualifier}s, because qualifiers are not
    4427 included in types. The assertion ``\lstinline$|ptr_to( Safe_pointer, int )$'' should be read as
    4428 ``\lstinline$Safe_pointer$ acts like a pointer to \lstinline$int$''.
    4429 \begin{lstlisting}
    4430 context ptr_to( type P | pointer( P ), type T ) {@\impl{ptr_to}@@\use{pointer}@
    4431         lvalue T *?( P ); lvalue T ?[?]( P, long int );
    4432 };
    4433 
    4434 context ptr_to_const( type P | pointer( P ), type T ) {@\impl{ptr_to_const}@
    4435         const lvalue T *?( P ); const lvalue T ?[?]( P, long int );@\use{pointer}@
    4436 };
    4437 
    4438 context ptr_to_volatile( type P | pointer( P ), type T ) }@\impl{ptr_to_volatile}@
    4439         volatile lvalue T *?( P ); volatile lvalue T ?[?]( P, long int );@\use{pointer}@
    4440 };
    4441 \end{lstlisting}
    4442 \begin{lstlisting}
    4443 context ptr_to_const_volatile( type P | pointer( P ), type T ) }@\impl{ptr_to_const_volatile}@
    4444         const volatile lvalue T *?( P );@\use{pointer}@
    4445         const volatile lvalue T ?[?]( P, long int );
    4446 };
    4447 \end{lstlisting}
    4448 
    4449 Assignment to pointers is more complicated than is the case with other types, because the target's
    4450 type can have extra type qualifiers in the pointed-at type: a ``\lstinline$T *$'' can be assigned to
    4451 a ``\lstinline$const T *$'', a ``\lstinline$volatile T *$'', and a ``\lstinline$const volatile T *$''.
    4452 Again, the pointed-at type is passed in, so that assertions can connect these specifications to the
    4453 ``\lstinline$ptr_to$'' specifications.
    4454 \begin{lstlisting}
    4455 context m_l_ptr_to( type P | m_l_pointer( P ),@\use{m_l_pointer}@@\impl{m_l_ptr_to}@ type T | ptr_to( P, T )@\use{ptr_to}@ {
    4456         P ?=?( P *, T * );
    4457         T * ?=?( T **, P );
    4458 };
    4459 
    4460 context m_l_ptr_to_const( type P | m_l_pointer( P ),@\use{m_l_pointer}@@\impl{m_l_ptr_to_const}@ type T | ptr_to_const( P, T )@\use{ptr_to_const}@) {
    4461         P ?=?( P *, const T * );
    4462         const T * ?=?( const T **, P );
    4463 };
    4464 
    4465 context m_l_ptr_to_volatile( type P | m_l_pointer( P ),@\use{m_l_pointer}@@\impl{m_l_ptr_to_volatile}@ type T | ptr_to_volatile( P, T )) {@\use{ptr_to_volatile}@
    4466         P ?=?( P *, volatile T * );
    4467         volatile T * ?=?( volatile T **, P );
    4468 };
    4469 
    4470 context m_l_ptr_to_const_volatile( type P | ptr_to_const_volatile( P ),@\use{ptr_to_const_volatile}@@\impl{m_l_ptr_to_const_volatile}@
    4471                 type T | m_l_ptr_to_volatile( P, T ) | m_l_ptr_to_const( P )) {@\use{m_l_ptr_to_const}@@\use{m_l_ptr_to_volatile}@
    4472         P ?=?( P *, const volatile T * );
    4473         const volatile T * ?=?( const volatile T **, P );
    4474 };
    4475 \end{lstlisting}
    4476 
    4477 Note the regular manner in which type qualifiers appear in those specifications. An alternative
    4478 specification can make use of the fact that qualification of the pointed-at type is part of a
    4479 pointer type to capture that regularity.
    4480 \begin{lstlisting}
    4481 context m_l_ptr_like( type MyP | m_l_pointer( MyP ),@\use{m_l_pointer}@@\impl{m_l_ptr_like}@ type CP | m_l_pointer( CP ) ) {
    4482         MyP ?=?( MyP *, CP );
    4483         CP ?=?( CP *, MyP );
    4484 };
    4485 \end{lstlisting}
    4486 The assertion ``\lstinline$| m_l_ptr_like( Safe_ptr, const int * )$'' should be read as
    4487 ``\lstinline$Safe_ptr$ is a pointer type like \lstinline$const int *$''. This specification has two
    4488 defects, compared to the original four: there is no automatic assertion that dereferencing a
    4489 \lstinline$MyP$ produces an lvalue of the type that \lstinline$CP$ points at, and the
    4490 ``\lstinline$|m_l_pointer( CP )$'' assertion provides only a weak assurance that the argument passed
    4491 to \lstinline$CP$ really is a pointer type.
    4492 
    4493 
    4494 \section{Relationships between operations}
    4495 
    4496 Different operators often have related meanings; for instance, in C, ``\lstinline$+$'',
    4497 ``\lstinline$+=$'', and the two versions of ``\lstinline$++$'' perform variations of addition.
    4498 Languages like {\CC} and Ada allow programmers to define operators for new types, but do not
    4499 require that these relationships be preserved, or even that all of the operators be implemented.
    4500 Completeness and consistency is left to the good taste and discretion of the programmer. It is
    4501 possible to encourage these attributes by providing generic operator functions, or member functions
    4502 of abstract classes, that are defined in terms of other, related operators.
    4503 
    4504 In \CFA, polymorphic functions provide the equivalent of these generic operators, and
    4505 specifications explicitly define the minimal implementation that a programmer should provide. This
    4506 section shows a few examples.
    4507 
    4508 
    4509 \subsection{Relational and equality operators}
    4510 
    4511 The different comparison operators have obvious relationships, but there is no obvious subset of the
    4512 operations to use in the implementation of the others. However, it is usually convenient to
    4513 implement a single comparison function that returns a negative integer, 0, or a positive integer if
    4514 its first argument is respectively less than, equal to, or greater than its second argument; the
    4515 library function \lstinline$strcmp$ is an example.
    4516 
    4517 C and \CFA have an extra, non-obvious comparison operator: ``\lstinline$!$'', logical negation,
    4518 returns 1 if its operand compares equal to 0, and 0 otherwise.
    4519 \begin{lstlisting}
    4520 context comparable( type T ) {
    4521         const T 0;
    4522         int compare( T, T );
    4523 }
    4524 
    4525 forall( type T | comparable( T ) ) int ?<?( T l, T r ) {
    4526         return compare( l, r ) < 0;
    4527 }
    4528 // ... similarly for <=, ==, >=, >, and !=.
    4529 
    4530 forall( type T | comparable( T ) ) int !?( T operand ) {
    4531         return !compare( operand, 0 );
    4532 }
    4533 \end{lstlisting}
    4534 
    4535 
    4536 \subsection{Arithmetic and integer operations}
    4537 
    4538 A complete arithmetic type would provide the arithmetic operators and the corresponding assignment
    4539 operators. Of these, the assignment operators are more likely to be implemented directly, because
    4540 it is usually more efficient to alter the contents of an existing object than to create and return a
    4541 new one. Similarly, a complete integral type would provide integral operations based on integral
    4542 assignment operations.
    4543 \begin{lstlisting}
    4544 context arith_base( type T ) {
    4545         const T 1;
    4546         T ?+=?( T *, T ), ?-=?( T *, T ), ?*=?( T *, T ), ?/=?( T *, T );
    4547 }
    4548 
    4549 forall( type T | arith_base( T ) ) T ?+?( T l, T r ) {
    4550         return l += r;
    4551 }
    4552 
    4553 forall( type T | arith_base( T ) ) T ?++( T * operand ) {
    4554         T temporary = *operand;
    4555         *operand += 1;
    4556         return temporary;
    4557 }
    4558 
    4559 forall( type T | arith_base( T ) ) T ++?( T * operand ) {
    4560         return *operand += 1;
    4561 }
    4562 // ... similarly for -, --, *, and /.
    4563 
    4564 context int_base( type T ) {
    4565         T ?&=?( T *, T ), ?|=?( T *, T ), ?^=?( T *, T );
    4566         T ?%=?( T *, T ), ?<<=?( T *, T ), ?>>=?( T *, T );
    4567 }
    4568 
    4569 forall( type T | int_base( T ) ) T ?&?( T l, T r ) {
    4570         return l &= r;
    4571 }
    4572 // ... similarly for |, ^, %, <<, and >>.
    4573 \end{lstlisting}
    4574 
    4575 Note that, although an arithmetic type would certainly provide comparison functions, and an integral
    4576 type would provide arithmetic operations, there does not have to be any relationship among
    4577 \lstinline$int_base$, \lstinline$arith_base$ and \lstinline$comparable$. Note also that these
    4578 declarations provide guidance and assistance, but they do not define an absolutely minimal set of
    4579 requirements. A truly minimal implementation of an arithmetic type might only provide
    4580 \lstinline$0$, \lstinline$1$, and \lstinline$?-=?$, which would be used by polymorphic
    4581 \lstinline$?+=?$, \lstinline$?*=?$, and \lstinline$?/=?$ functions.
    4582 
    4583 Note also that \lstinline$short$ is an integer type in C11 terms, but has no operations!
    4584 
    4585 
    4586 \chapter{TODO}
    4587 Review index entries.
    4588 
    4589 Restrict allowed to qualify anything, or type/dtype parameters, but only affects pointers. This gets
    4590 into \lstinline$noalias$ territory. Qualifying anything (``\lstinline$short restrict rs$'') means
    4591 pointer parameters of \lstinline$?++$, etc, would need restrict qualifiers.
    4592 
    4593 Enumerated types. Constants are not ints. Overloading. Definition should be ``representable as an
    4594 integer type'', not ``as an int''. C11 usual conversions freely convert to and from ordinary
    4595 integer types via assignment, which works between any integer types. Does enum Color ?*?( enum
    4596 Color, enum Color ) really make sense? ?++ does, but it adds (int)1.
    4597 
    4598 Operators on {,signed,unsigned} char and other small types. ?<? harmless; ?*? questionable for
    4599 chars. Generic selections make these choices visible. Safe conversion operators? Predefined
    4600 ``promotion'' function?
    4601 
    4602 \lstinline$register$ assignment might be handled as assignment to a temporary with copying back and
    4603 forth, but copying must not be done by assignment.
    4604 
    4605 Don't use ptrdiff\_t by name in the predefineds.
    4606 
    4607 Polymorphic objects. Polymorphic typedefs and type declarations.
    4608 
    4609 
    4610 \bibliographystyle{plain}
    4611 \bibliography{refrat}
    4612 
    4613 
    4614 \addcontentsline{toc}{chapter}{\indexname} % add index name to table of contents
    4615 \begin{theindex}
    4616 Italic page numbers give the location of the main entry for the referenced term. Plain page numbers
    4617 denote uses of the indexed term. Entries for grammar non-terminals are italicized. A typewriter
    4618 font is used for grammar terminals and program identifiers.
    4619 \indexspace
    4620 \input{refrat.ind}
    4621 \end{theindex}
    4622 
    4623 \end{document}
    4624 
    4625 % Local Variables: %
    4626 % tab-width: 4 %
    4627 % fill-column: 100 %
    4628 % compile-command: "make" %
    4629 % End: %

  • src/CodeGen/CodeGenerator.cc

    rb0be06ac r59cde21  
    1010// Created On       : Mon May 18 07:44:20 2015
    1111// Last Modified By : Rob Schluntz
    12 // Last Modified On : Thu Sep 17 15:25:58 2015
    13 // Update Count     : 233
     12// Last Modified On : Wed Aug 12 14:33:52 2015
     13// Update Count     : 222
    1414//
    1515
    … …  
    190190                if ( designators.size() == 0 ) return;
    191191                for ( DesignatorList::iterator iter = designators.begin(); iter != designators.end(); ++iter ) {
    192                         if ( dynamic_cast< NameExpr * >( *iter ) ) {
     192                        if ( NameExpr * nm = dynamic_cast< NameExpr * >( *iter ) ) {
    193193                                // if expression is a name, then initializing aggregate member
    194194                                output << ".";
    … …  
    258258             
    259259                                  case OT_CALL:
    260                                   case OT_CTOR:
    261                                   case OT_DTOR:
    262                                         // there are no intrinsic definitions of the function call operator or constructors or destructors
     260                                        // there are no intrinsic definitions of the function call operator
    263261                                        assert( false );
    264262                                        break;
    … …  
    324322             
    325323                                  case OT_CALL:
    326                                         case OT_CTOR:
    327                                         case OT_DTOR:
    328324                                        assert( false );
    329325                                        break;
    … …  
    396392
    397393        void CodeGenerator::visit( CastExpr *castExpr ) {
    398                 // if the cast is to an lvalue type, then the cast
    399                 // should be dropped, since the result of a cast is
    400                 // never an lvalue in C
    401                 if ( castExpr->get_results().front()->get_isLvalue() ) {
    402                         castExpr->get_arg()->accept( *this );
    403                 } else {
    404                         output << "((";
    405                         if ( castExpr->get_results().empty() ) {
    406                                 output << "void" ;
    407                         } else {
    408                                 output << genType( castExpr->get_results().front(), "" );
    409                         } // if
    410                         output << ")";
    411                         castExpr->get_arg()->accept( *this );
    412                         output << ")";                 
    413                 }
     394                output << "((";
     395                if ( castExpr->get_results().empty() ) {
     396                        output << "void" ;
     397                } else {
     398                        output << genType( castExpr->get_results().front(), "" );
     399                } // if
     400                output << ")";
     401                castExpr->get_arg()->accept( *this );
     402                output << ")";
    414403        }
    415404 

  • src/CodeGen/OperatorTable.cc

    rb0be06ac r59cde21  
    99// Author           : Richard C. Bilson
    1010// Created On       : Mon May 18 07:44:20 2015
    11 // Last Modified By : Rob Schluntz
    12 // Last Modified On : Tue Oct 06 15:26:34 2015
    13 // Update Count     : 9
     11// Last Modified By : Peter A. Buhr
     12// Last Modified On : Tue Jun 23 17:41:14 2015
     13// Update Count     : 5
    1414//
    1515
    … …  
    2121                const OperatorInfo tableValues[] = {
    2222                        {       "?[?]",         "",             "_operator_index",                              OT_INDEX                        },
    23                         {       "?{}",          "",             "_constructor",                                 OT_CTOR                         },
    24                         {       "^?{}",         "",             "_destructor",                                  OT_DTOR                         }, // ~?{}, -?{}, !?{}, $?{}, ??{}, ^?{}, ?destroy, ?delete
    2523                        {       "?()",          "",             "_operator_call",                               OT_CALL                         },
    2624                        {       "?++",          "++",   "_operator_postincr",                   OT_POSTFIXASSIGN        },

  • src/CodeGen/OperatorTable.h

    rb0be06ac r59cde21  
    99// Author           : Richard C. Bilson
    1010// Created On       : Mon May 18 07:44:20 2015
    11 // Last Modified By : Rob Schluntz
    12 // Last Modified On : Wed Jun 24 16:17:57 2015
    13 // Update Count     : 5
     11// Last Modified By : Peter A. Buhr
     12// Last Modified On : Tue Jun 23 16:09:27 2015
     13// Update Count     : 3
    1414//
    1515
    … …  
    2222        enum OperatorType {
    2323                OT_INDEX,
    24                 OT_CTOR,
    25                 OT_DTOR,
    2624                OT_CALL,
    2725                OT_PREFIX,

  • src/GenPoly/Specialize.cc

    rb0be06ac r59cde21  
    99// Author           : Richard C. Bilson
    1010// Created On       : Mon May 18 07:44:20 2015
    11 // Last Modified By : Rob Schluntz
    12 // Last Modified On : Tue Sep 22 14:04:13 2015
    13 // Update Count     : 15
     11// Last Modified By : Peter A. Buhr
     12// Last Modified On : Sat Jun 13 15:54:07 2015
     13// Update Count     : 6
    1414//
    1515
    … …  
    8686
    8787        Expression * Specialize::doSpecialization( Type *formalType, Expression *actual, InferredParams *inferParams ) {
    88                 assert( ! actual->get_results().empty() );
    8988                if ( needsSpecialization( formalType, actual->get_results().front(), env ) ) {
    9089                        PointerType *ptrType;
    … …  
    168167        Expression * Specialize::mutate( AddressExpr *addrExpr ) {
    169168                addrExpr->get_arg()->acceptMutator( *this );
    170                 assert( ! addrExpr->get_results().empty() );
    171169                addrExpr->set_arg( doSpecialization( addrExpr->get_results().front(), addrExpr->get_arg() ) );
    172170                return addrExpr;
    … …  
    175173        Expression * Specialize::mutate( CastExpr *castExpr ) {
    176174                castExpr->get_arg()->acceptMutator( *this );
    177                 if ( ! castExpr->get_results().empty() ) {
    178                         // this may not be the correct condition, but previously the next statement
    179                         // was happening unchecked, causing a crash on a cast to void
    180                         castExpr->set_arg( doSpecialization( castExpr->get_results().front(), castExpr->get_arg() ) );         
    181                 }
     175                castExpr->set_arg( doSpecialization( castExpr->get_results().front(), castExpr->get_arg() ) );
    182176                return castExpr;
    183177        }

  • src/MakeLibCfa.cc

    rb0be06ac r59cde21  
    99// Author           : Richard C. Bilson
    1010// Created On       : Sat May 16 10:33:33 2015
    11 // Last Modified By : Rob Schluntz
    12 // Last Modified On : Fri Jul 03 18:11:37 2015
    13 // Update Count     : 18
     11// Last Modified By : Peter A. Buhr
     12// Last Modified On : Fri Jun 26 16:52:59 2015
     13// Update Count     : 14
    1414//
    1515
    … …  
    7777                                break;
    7878                        }
    79                   case CodeGen::OT_CTOR:
    80                   case CodeGen::OT_DTOR:
    8179                  case CodeGen::OT_CONSTANT:
    8280                  case CodeGen::OT_LABELADDRESS:

  • src/Parser/ParseNode.h

    rb0be06ac r59cde21  
    1010// Created On       : Sat May 16 13:28:16 2015
    1111// Last Modified By : Rob Schluntz
    12 // Last Modified On : Wed Aug 19 15:59:27 2015
    13 // Update Count     : 174
     12// Last Modified On : Wed Aug 12 13:27:11 2015
     13// Update Count     : 172
    1414//
    1515
    … …  
    180180                                Assign, MulAssn, DivAssn, ModAssn, PlusAssn, MinusAssn, LSAssn, RSAssn, AndAssn,
    181181                                ERAssn, OrAssn, Index, FieldSel, PFieldSel, Range,
    182                                 UnPlus, UnMinus, AddressOf, PointTo, Neg, BitNeg, Incr, IncrPost, Decr, DecrPost, LabelAddress,
    183                                 Ctor, Dtor,
     182                                UnPlus, UnMinus, AddressOf, PointTo, Neg, BitNeg, Incr, IncrPost, Decr, DecrPost, LabelAddress
    184183        };
    185184

  • src/SymTab/Indexer.h

    rb0be06ac r59cde21  
    1010// Created On       : Sun May 17 21:38:55 2015
    1111// Last Modified By : Rob Schluntz
    12 // Last Modified On : Thu Sep 17 16:05:38 2015
    13 // Update Count     : 5
     12// Last Modified On : Wed Aug 05 13:51:39 2015
     13// Update Count     : 4
    1414//
    1515
    … …  
    1919#include <list>
    2020#include <string>
     21#include <map>
    2122
    2223#include "SynTree/Visitor.h"

  • src/SynTree/Expression.cc

    rb0be06ac r59cde21  
    1010// Created On       : Mon May 18 07:44:20 2015
    1111// Last Modified By : Rob Schluntz
    12 // Last Modified On : Wed Sep 02 12:07:10 2015
    13 // Update Count     : 33
     12// Last Modified On : Wed Aug 12 14:02:45 2015
     13// Update Count     : 30
    1414//
    1515
    … …  
    3131Expression::Expression( Expression *_aname ) : env( 0 ), argName( _aname ) {}
    3232
    33 Expression::Expression( const Expression &other ) : env( maybeClone( other.env ) ), argName( maybeClone( other.get_argName() ) ) {
     33Expression::Expression( const Expression &other ) : env( maybeClone( other.env ) ) {
    3434        cloneAll( other.results, results );
     35        argName = other.get_argName();
    3536}
    3637
Note: See TracChangeset for help on using the changeset viewer.