source: doc/refrat/refrat.tex @ e945826

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

formatting in iostream.c, and change escape sequences in documentation

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