source: doc/refrat/refrat.tex @ bfee448

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

fix *predefined* macro and associated sed script

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