source: doc/refrat/refrat.tex @ 01414f1

aaron-thesisarm-ehcleanup-dtorsctordeferred_resndemanglerenumforall-pointer-decaygc_noraiijacob/cs343-translationjenkins-sandboxmemorynew-astnew-ast-unique-exprnew-envno_listpersistent-indexerpthread-emulationqualifiedEnumresolv-newstringwith_gc
Last change on this file since 01414f1 was 01414f1, checked in by Glen Ditchfield <gjditchfield@…>, 7 years ago

Added Peter as an author

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