source: doc/refrat/refrat.tex @ cf16f94

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

create temporary return variable for return expressions, remove unnecessary code after temporary-return-variable change, fix missing lvalue qualifiers, change stream operator to |

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