source: doc/refrat/refrat.tex @ 7937abf

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

update examples with new keywords, more formatting changes in documentation

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