source: doc/refrat/refrat.tex @ 9460586

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

fix special characters in sanserif font, and use inline index

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