source: doc/refrat/refrat.tex @ aa99647

aaron-thesisarm-ehcleanup-dtorsctordeferred_resndemanglerenumforall-pointer-decaygc_noraiijacob/cs343-translationjenkins-sandboxmemorynew-astnew-ast-unique-exprnew-envno_listpersistent-indexerresolv-newstringwith_gc
Last change on this file since aa99647 was f60d997, checked in by Peter A. Buhr <pabuhr@…>, 7 years ago

refrat initial commit

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