Changeset d2ded3e7 for doc


Ignore:
Timestamp:
Oct 28, 2015, 3:47:29 PM (10 years ago)
Author:
Aaron Moss <a3moss@…>
Branches:
ADT, aaron-thesis, arm-eh, ast-experimental, cleanup-dtors, ctor, deferred_resn, demangler, enum, forall-pointer-decay, gc_noraii, jacob/cs343-translation, jenkins-sandbox, master, memory, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, pthread-emulation, qualifiedEnum, resolv-new, string, with_gc
Children:
37a3b8f9, 4673385, e56cfdb0
Parents:
698664b3 (diff), 097e2b0 (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the (diff) links above to see all the changes relative to each parent.
Message:

Merge changes into current branch

Location:
doc
Files:
4 added
3 deleted
1 edited

Legend:

Unmodified
Added
Removed

  • doc/refrat/refrat.tex

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