source: doc/refrat/refrat.tex @ 37e9c1d

ADTast-experimentalenumpthread-emulationqualifiedEnum
Last change on this file since 37e9c1d was 14d71ed, checked in by Peter A. Buhr <pabuhr@…>, 4 years ago

update to CFAStyle macro

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