source: doc/refrat/refrat.tex @ e55ca05

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

fix bibliography for manuals, refactor common LaTeX macros

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