source: doc/refrat/refrat.tex @ 865249a

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

correct error

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