source: doc/refrat/refrat.tex @ a1edafa

ADTaaron-thesisarm-ehast-experimentalcleanup-dtorsdeferred_resndemanglerenumforall-pointer-decayjacob/cs343-translationjenkins-sandboxnew-astnew-ast-unique-exprnew-envno_listpersistent-indexerpthread-emulationqualifiedEnumresolv-newwith_gc
Last change on this file since a1edafa was 83e9bd3, checked in by Peter A. Buhr <pabuhr@…>, 7 years ago

formatting updates

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