source: doc/refrat/refrat.tex @ 9909842

ADTaaron-thesisarm-ehast-experimentalcleanup-dtorsctordeferred_resndemanglerenumforall-pointer-decaygc_noraiijacob/cs343-translationjenkins-sandboxmemorynew-astnew-ast-unique-exprnew-envno_listpersistent-indexerpthread-emulationqualifiedEnumresolv-newstringwith_gc
Last change on this file since 9909842 was 097e2b0, checked in by Peter A. Buhr <pabuhr@…>, 8 years ago

constructor/destructor, more example programs

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