Changeset f60d997


Ignore:
Timestamp:
Sep 11, 2015, 9:44:18 AM (6 years ago)
Author:
Peter A. Buhr <pabuhr@…>
Branches:
aaron-thesis, arm-eh, cleanup-dtors, ctor, deferred_resn, demangler, gc_noraii, jacob/cs343-translation, jenkins-sandbox, master, memory, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, resolv-new, string, with_gc
Children:
aa99647
Parents:
09f800b
Message:

refrat initial commit

Location:
doc
Files:
5 added
3 deleted
1 edited

Legend:

Unmodified
Added
Removed
  • doc/refrat/refrat.tex

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