source: doc/refrat/refrat.tex @ 0638c44

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

more formatting changes to documents, update I/O for examples

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