source: doc/refrat/refrat.tex @ 20e409e

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

make *predefined* declarations work

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