source: doc/refrat/refrat.tex @ 90c3b1c

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

compile CFA with C++11, further update refrat with lstlisting macros, support varags, enumeration initialization, add implicit separators to output streams, update example programs that print

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