source: doc/refrat/refrat.tex @ 53ba273

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

switch from std=c99 to std=gnu99, update latex macros, refrat and extend user manual, update limits/iostream/fstream, add rational numbers

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