source: doc/refrat/refrat.tex @ b63e376

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

update refrat with new keywords, update examples, update separators for quoted strings

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