source: doc/refrat/refrat.tex @ 41b3ddd

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 41b3ddd was 41b3ddd, checked in by Peter A. Buhr <pabuhr@…>, 7 years ago

begin documentation for generic types

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