source: doc/refrat/refrat.tex @ a752883

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

.gitignore all latex auxiliary files, latex changes for refrat

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