Changeset a5a71d0


Ignore:
Timestamp:
Apr 6, 2016, 5:11:32 PM (7 years ago)
Author:
Rob Schluntz <rschlunt@…>
Branches:
ADT, aaron-thesis, arm-eh, 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, with_gc
Children:
eab39cd
Parents:
39786813 (diff), 3aba311 (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 branch 'fix-memory-error' into ctor

Conflicts:

src/CodeGen/CodeGenerator.cc
src/Makefile.in
src/Parser/DeclarationNode.cc
src/Parser/ParseNode.h
src/Parser/TypeData.cc
src/Parser/parser.cc
src/Parser/parser.yy
src/ResolvExpr/Resolver.cc
src/SymTab/Validate.cc
src/SynTree/Declaration.h
src/SynTree/Mutator.cc
src/SynTree/Mutator.h
src/SynTree/SynTree.h
src/SynTree/Visitor.cc
src/SynTree/Visitor.h
src/libcfa/prelude.cf

Files:
6 added
21 deleted
109 edited

Legend:

Unmodified
Added
Removed

  • .gitignore

    r39786813 ra5a71d0  
    3030
    3131# generated by latex
    32 doc/refrat/refrat.aux
    33 doc/refrat/refrat.bbl
    34 doc/refrat/refrat.blg
    35 doc/refrat/refrat.brf
    36 doc/refrat/refrat.dvi
    37 doc/refrat/refrat.idx
    38 doc/refrat/refrat.ilg
    39 doc/refrat/refrat.ind
    40 doc/refrat/refrat.log
    41 doc/refrat/refrat.out
    42 doc/refrat/refrat.pdf
    43 doc/refrat/refrat.ps
    44 doc/refrat/refrat.toc
     32*.aux
     33*.bbl
     34*.blg
     35*.brf
     36*.dvi
     37*.idx
     38*.ilg
     39*.ind
     40*.log
     41*.out
     42*.pdf
     43*.ps
     44*.toc

  • configure

    r39786813 ra5a71d0  
    24092409
    24102410
     2411if test "x${CXXFLAGS}" = "x"; then
     2412   export CXXFLAGS="-std=c++11 -g -O2 ${CXXFLAGS}"
     2413else
     2414   export CXXFLAGS="-std=c++11 ${CXXFLAGS}"
     2415fi
     2416
    24112417am__api_version='1.11'
    24122418

  • configure.ac

    r39786813 ra5a71d0  
    77#AC_CONFIG_SRCDIR([src/main.cc])
    88AC_CONFIG_HEADERS([config.h])
     9
     10if test "x${CXXFLAGS}" = "x"; then
     11   export CXXFLAGS="-std=c++11 -g -O2 ${CXXFLAGS}"
     12else
     13   export CXXFLAGS="-std=c++11 ${CXXFLAGS}"
     14fi
    915
    1016AM_INIT_AUTOMAKE

  • doc/refrat/Makefile

    r39786813 ra5a71d0  
    11## Define the appropriate configuration variables.
    22
    3 TeXLIB = .::
     3Macros =
     4TeXLIB = .:${Macros}:
    45LaTeX  = TEXINPUTS=${TeXLIB} && export TEXINPUTS && latex
    56BibTeX = BSTINPUTS=${TeXLIB} && export BSTINPUTS && bibtex

  • doc/refrat/refrat.tex

    r39786813 ra5a71d0  
    1717\usepackage[dvips,plainpages=false,pdfpagelabels,pdfpagemode=UseNone,colorlinks=true,pagebackref=true,linkcolor=blue,citecolor=blue,urlcolor=blue,pagebackref=true,breaklinks=true]{hyperref}
    1818\usepackage{breakurl}
    19 \urlstyle{sf}
     19\renewcommand{\UrlFont}{\small\sf}
    2020
    2121%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    … …  
    2323% Names used in the document.
    2424
    25 \newcommand{\CFA}{Cforall\xspace}               % set language text name
    26 \newcommand{\CFAA}{C$\forall$\xspace}   % set language symbolic name
     25\newcommand{\CFA}{C$\forall$\xspace}    % set language symbolic name
     26\newcommand{\CFL}{Cforall\xspace}               % set language text name
    2727\newcommand{\CC}{C\kern-.1em\hbox{+\kern-.25em+}\xspace} % CC symbolic name
    2828\def\c11{ISO/IEC C} % C11 name (cannot have numbers in latex command name)
    … …  
    3333
    3434\makeatletter
     35% allow escape sequence in lstinline
     36%\usepackage{etoolbox}
     37%\patchcmd{\lsthk@TextStyle}{\let\lst@DefEsc\@empty}{}{}{\errmessage{failed to patch}}
     38
     39\renewcommand\small{%
     40   \@setfontsize\small{8.5}{11}%
     41   \abovedisplayskip 8.5pt \@plus 3pt \@minus 4pt
     42   \abovedisplayshortskip \z@ \@plus 2pt
     43   \belowdisplayshortskip 4pt \@plus 2pt \@minus 2pt
     44   \def\@listi{\leftmargin\leftmargini
     45               \topsep 4pt \@plus 2pt \@minus 2pt
     46               \parsep 2pt \@pluspt \@minuspt
     47               \itemsep \parsep}%
     48   \belowdisplayskip \abovedisplayskip
     49}
     50\usepackage{relsize}            % must be after change to small
     51
     52\renewcommand{\labelitemi}{{\raisebox{0.25ex}{\footnotesize$\bullet$}}}
     53\renewenvironment{itemize}{\begin{list}{\labelitemi}{\topsep=5pt\itemsep=5pt\parsep=0pt}}{\end{list}}
     54
     55%  Reduce size of chapter/section titles
     56\def\@makechapterhead#1{%
     57  \vspace*{50\p@}%
     58  {\parindent \z@ \raggedright \normalfont
     59    \ifnum \c@secnumdepth >\m@ne
     60        \large\bfseries \@chapapp\space \thechapter
     61        \par\nobreak
     62        \vskip 5\p@
     63    \fi
     64    \interlinepenalty\@M
     65    \Large \bfseries #1\par\nobreak
     66    \vskip 50\p@
     67  }}
     68\def\@makeschapterhead#1{%
     69  \vspace*{50\p@}%
     70  {\parindent \z@ \raggedright
     71    \normalfont
     72    \interlinepenalty\@M
     73    \Large \bfseries  #1\par\nobreak
     74    \vskip 50\p@
     75  }}
     76\renewcommand\section{\@startsection{section}{1}{\z@}{-3.0ex \@plus -1ex \@minus -.2ex}{1.0ex \@plus .2ex}{\normalfont\large\bfseries}}
     77\renewcommand\subsection{\@startsection{subsection}{2}{\z@}{-2.5ex \@plus -1ex \@minus -.2ex}{1.0ex \@plus .2ex}{\normalfont\normalsize\bfseries}}
     78\renewcommand\subsubsection{\@startsection{subsubsection}{3}{\z@}{-2.5ex \@plus -1ex \@minus -.2ex}{1.0ex \@plus .2ex}{\normalfont\normalsize\bfseries}}
     79\renewcommand\paragraph{\@startsection{paragraph}{4}{\z@}{-2.0ex \@plus -1ex \@minus -.2ex}{-1em}{\normalfont\normalsize\bfseries}}
     80
    3581% index macros
    3682\newcommand{\italic}[1]{\emph{\hyperpage{#1}}}
    … …  
    60106%\newcommand{\impl}[1]{\index{\protect#1@{\lstinline$\protect#1$}|definition}}
    61107
    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}
     108% inline text and lowercase index: \Index{inline and lowercase index text}
     109% inline text and as-in index: \Index[as-is index text]{inline text}
     110% inline text but index with different as-is text: \Index[index text]{inline text}
    65111\newcommand{\Index}{\@ifstar\@sIndex\@Index}
    66112\newcommand{\@Index}[2][\@empty]{\lowercase{\def\temp{#2}}#2\ifx#1\@empty\index{\temp}\else\index{#1@{\protect#2}}\fi}
    … …  
    69115
    70116% blocks and titles
    71 \newcommand{\define}[1]{\emph{#1\/}\index{#1}}
    72117\newenvironment{rationale}{%
    73118  \begin{quotation}\noindent$\Box$\enspace
    … …  
    75120  \hfill\enspace$\Box$\end{quotation}
    76121}%
     122\newcommand{\define}[1]{\emph{#1\/}\index{#1}}
    77123\newcommand{\rewrite}{\(\Rightarrow\)}
    78124\newcommand{\rewriterules}{\paragraph{Rewrite Rules}~\par\noindent}
    … …  
    103149\newcommand{\VPageref}[2][page]{\ifx#1\@empty\else{#1}\nobreakspace\fi\pageref{#2}}
    104150
    105 % adjust listings macros
     151% CFA based on ANSI C
    106152\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,},
     153{morekeywords={asm,_Alignas,_Alignof,_At,_Atomic,_Bool,catch,catchResume,choose,_Complex,trait,disable,dtype,enable,
     154        fallthru,finally,forall,ftype,_Generic,_Imaginary,inline,lvalue,_Noreturn,otype,restrict,_Static_assert,
     155        _Thread_local,throw,throwResume,try,},
    110156}%
    111157
    … …  
    113159language=CFA,
    114160columns=flexible,
    115 basicstyle=\sf\small,
     161basicstyle=\sf\relsize{-1},
    116162tabsize=4,
    117163xleftmargin=\parindent,
    118164escapechar=@,
    119165keepspaces=true,
    120 %showtabs=true,
    121 %tab=\rightarrowfill,
     166showstringspaces=false,
     167showlines=true,
    122168}%
    123169
    … …  
    145191\linenumbers                                    % comment out to turn off line numbering
    146192
    147 \title{\CFA (\CFAA) Reference Manual and Rationale}
    148 \author{Glen Ditchfield \and Peter A. Buhr}
    149 \date{DRAFT\\\today}
     193\title{\Huge
     194\CFA (\CFL) Reference Manual and Rationale
     195}% title
     196\author{\huge
     197Glen Ditchfield and Peter A. Buhr
     198}% author
     199\date{
     200DRAFT\\\today
     201}% date
    150202
    151203\pagenumbering{roman}
    … …  
    159211\copyright\,2015 Glen Ditchfield \\ \\
    160212\noindent
    161 This work is licensed under the Creative Commons Attribution 4.0 International License. To view a
    162 copy of this license, visit {\small\url{http://creativecommons.org/licenses/by/4.0}}.
     213This work is licensed under the Creative Commons Attribution 4.0 International License.
     214To view a copy of this license, visit {\small\url{http://creativecommons.org/licenses/by/4.0}}.
    163215\vspace*{1in}
    164216
    … …  
    173225\chapter*{Introduction}\addcontentsline{toc}{chapter}{Introduction}
    174226
    175 This document is a reference manual and rationale for \CFA, a polymorphic extension of the C
    176 programming language. It makes frequent reference to the {\c11} standard \cite{ANS:C11}, and
    177 occasionally compares \CFA to {\CC} \cite{c++}.
    178 
    179 The manual deliberately imitates the ordering of the {\c11} standard (although the section numbering
    180 differs). Unfortunately, this means the manual contains more ``forward references'' than usual,
    181 making it harder to follow if the reader does not have a copy of the {\c11} standard. For a simple
    182 introduction to \CFA, see the companion document ``An Overview of \CFA''
     227This document is a reference manual and rationale for \CFA, a polymorphic extension of the C programming language.
     228It makes frequent reference to the {\c11} standard \cite{ANS:C11}, and occasionally compares \CFA to {\CC} \cite{c++}.
     229
     230The manual deliberately imitates the ordering of the {\c11} standard (although the section numbering differs).
     231Unfortunately, this means the manual contains more ``forward references'' than usual, making it harder to follow if the reader does not have a copy of the {\c11} standard.
     232For a simple introduction to \CFA, see the companion document ``An Overview of \CFA''
    183233\cite{Ditchfield96:Overview}.
    184234
    185235\begin{rationale}
    186 Commentary (like this) is quoted with quads. Commentary usually deals with subtle points, the
    187 rationale behind a rule, and design decisions.
     236Commentary (like this) is quoted with quads.
     237Commentary usually deals with subtle points, the rationale behind a rule, and design decisions.
    188238\end{rationale}
    189239
    … …  
    194244\chapter{Terms, definitions, and symbols}
    195245
    196 Terms from the {\c11} standard used in this document have the same meaning as in the {\c11}
    197 standard.
     246Terms from the {\c11} standard used in this document have the same meaning as in the {\c11} standard.
    198247
    199248% No ``Conformance'' or ``Environment'' chapters yet.
    … …  
    205254
    206255\section{Notation}
    207 The syntax notation used in this document is the same as in the {\c11} standard, with one exception:
    208 ellipsis in the definition of a nonterminal, as in ``\emph{declaration:} \ldots'', indicates that
    209 these rules extend a previous definition, which occurs in this document or in the {\c11} standard.
     256The syntax notation used in this document is the same as in the {\c11} standard, with one exception: ellipsis in the definition of a nonterminal, as in ``\emph{declaration:} \ldots'', indicates that these rules extend a previous definition, which occurs in this document or in the {\c11} standard.
    210257
    211258
    … …  
    215262\subsection{Scopes of identifiers}\index{scopes}
    216263
    217 \CFA's scope rules differ from C's in one major respect: a declaration of an identifier may
    218 overload\index{overloading} outer declarations of lexically identical identifiers in the same
    219 \Index{name space}, instead of hiding them. The outer declaration is hidden if the two declarations
    220 have \Index{compatible type}, or if one declares an array type and the other declares a pointer type
    221 and the element type and pointed-at type are compatible, or if one has function type and the other
    222 is a pointer to a compatible function type, or if one declaration is a \lstinline$type$\use{type} or
     264\CFA's scope rules differ from C's in one major respect: a declaration of an identifier may overload\index{overloading} outer declarations of lexically identical identifiers in the same
     265\Index{name space}, instead of hiding them.
     266The outer declaration is hidden if the two declarations have \Index{compatible type}, or if one declares an array type and the other declares a pointer type and the element type and pointed-at type are compatible, or if one has function type and the other is a pointer to a compatible function type, or if one declaration is a \lstinline$type$\use{type} or
    223267\lstinline$typedef$\use{typedef} declaration and the other is not.  The outer declaration becomes
    224268\Index{visible} when the scope of the inner declaration terminates.
    225269\begin{rationale}
    226 Hence, a \CFA program can declare an \lstinline$int v$ and a \lstinline$float v$ in the same
    227 scope; a {\CC} program can not.
     270Hence, a \CFA program can declare an \lstinline$int v$ and a \lstinline$float v$ in the same scope;
     271a {\CC} program can not.
    228272\end{rationale}
    229273
    … …  
    232276\index{linkage}
    233277
    234 \CFA's linkage rules differ from C's in only one respect: instances of a particular identifier with
    235 external or internal linkage do not necessarily denote the same object or function. Instead, in the
    236 set of translation units and libraries that constitutes an entire program, any two instances of a
    237 particular identifier with \Index{external linkage} denote the same object or function if they have
    238 \Index{compatible type}s, or if one declares an array type and the other declares a pointer type and
    239 the element type and pointed-at type are compatible, or if one has function type and the other is a
    240 pointer to a compatible function type. Within one translation unit, each instance of an identifier
    241 with \Index{internal linkage} denotes the same object or function in the same circumstances.
     278\CFA's linkage rules differ from C's in only one respect: instances of a particular identifier with external or internal linkage do not necessarily denote the same object or function.
     279Instead, in the set of translation units and libraries that constitutes an entire program, any two instances of a particular identifier with \Index{external linkage} denote the same object or function if they have
     280\Index{compatible type}s, or if one declares an array type and the other declares a pointer type and the element type and pointed-at type are compatible, or if one has function type and the other is a pointer to a compatible function type.
     281Within one translation unit, each instance of an identifier with \Index{internal linkage} denotes the same object or function in the same circumstances.
    242282Identifiers with \Index{no linkage} always denote unique entities.
    243283\begin{rationale}
    244 A \CFA program can declare an \lstinline$extern int v$ and an \lstinline$extern float v$; a C
    245 program cannot.
     284A \CFA program can declare an \lstinline$extern int v$ and an \lstinline$extern float v$;
     285a C program cannot.
    246286\end{rationale}
    247287
    … …  
    253293\subsubsection{Semantics}
    254294
    255 \CFA provides a capability for generic types; using this capability a single "generic type
    256 generator" can be written that can represent multiple concrete type instantiations by substitution
    257 of the "type parameters" of the generic type for concrete types. Syntactically a generic type
    258 generator is represented by putting a forall specifier on a struct or union declaration, as defined
    259 in \VRef{forall}. An instantiation of the generic type is written by specifying the type parameters
    260 in parentheses after the name of the generic type generator:
    261 \begin{lstlisting}
    262 forall( type T | sumable( T ) ) struct pair {
     295\CFA provides a capability for generic types;
     296using this capability a single "generic type generator" can be written that can represent multiple concrete type instantiations by substitution of the "type parameters" of the generic type for concrete types.
     297Syntactically a generic type generator is represented by putting a forall specifier on a struct or union declaration, as defined in \VRef{forall}.
     298An instantiation of the generic type is written by specifying the type parameters in parentheses after the name of the generic type generator:
     299\begin{lstlisting}
     300forall( otype T | sumable( T ) ) struct pair {
    263301        T x;
    264302        T y;
    … …  
    267305\end{lstlisting}
    268306
    269 The type parameters in an instantiation of a generic type must satisfy any constraints in the forall
    270 specifier on the type generator declaration, e.g., \lstinline$sumable$. The instantiation then has
    271 the semantics that would result if the type parameters were substituted into the type generator
    272 declaration by macro substitution.
    273 
    274 Polymorphic functions may have generic types as parameters, and those generic types may use type
    275 parameters of the polymorphic function as type parameters of the generic type:
    276 \begin{lstlisting}
    277 forall( type T ) void swap( pair(T) *p ) {
     307The type parameters in an instantiation of a generic type must satisfy any constraints in the forall specifier on the type generator declaration, e.g., \lstinline$sumable$.
     308The instantiation then has the semantics that would result if the type parameters were substituted into the type generator declaration by macro substitution.
     309
     310Polymorphic functions may have generic types as parameters, and those generic types may use type parameters of the polymorphic function as type parameters of the generic type:
     311\begin{lstlisting}
     312forall( otype T ) void swap( pair(T) *p ) {
    278313        T z = p->x;
    279314        p->x = p->y;
    … …  
    285320\subsubsection{Constraints}
    286321
    287 To avoid unduly constraining implementors, the generic type generator definition must be visible at
    288 any point where it is instantiated.  Forward declarations of generic type generators are not
    289 forbidden, but the definition must be visible to instantiate the generic type.  Equivalently,
    290 instantiations of generic types are not allowed to be incomplete types.
     322To avoid unduly constraining implementors, the generic type generator definition must be visible at any point where it is instantiated.
     323Forward declarations of generic type generators are not forbidden, but the definition must be visible to instantiate the generic type.  Equivalently, instantiations of generic types are not allowed to be incomplete types.
    291324
    292325\examples
    293326\begin{lstlisting}
    294 forall( type T ) struct A;
    295 
    296 forall( type T ) struct B {
    297         A(T) *a;  // legal, but cannot instantiate B(T)
     327forall( otype T ) struct A;
     328
     329forall( otype T ) struct B {
     330        A(T) *a;                        // legal, but cannot instantiate B(T)
    298331};
    299332
    300 B(T) x; // illegal, *x.a is of an incomplete generic type
    301 
    302 forall( type T ) struct A {
     333B(T) x;                                 // illegal, *x.a is of an incomplete generic type
     334 
     335forall( otype T ) struct A {
    303336        B( T ) *b;
    304337};
    305338
    306 B( T ) y; // legal, *x.a is now of a complete generic type
    307 
     339B( T ) y;                               // legal, *x.a is now of a complete generic type
    308340
    309341// box.h:
    310         forall( type T ) struct box;
    311         forall( type T ) box( T ) *make_box( T );
    312         forall( type T ) void use_box( box( T ) *b );
     342        forall( otype T ) struct box;
     343        forall( otype T ) box( T ) *make_box( T );
     344        forall( otype T ) void use_box( box( T ) *b );
    313345       
    314346// main.c:
    315         box( int ) *b = make_box( 42 ); // illegal, def'n of box not visible
    316         use_box( b ); // illegal
     347        box( int ) *b = make_box( 42 ); // illegal, definition of box not visible
     348        use_box( b );           // illegal
    317349\end{lstlisting}
    318350
    … …  
    320352\section{Conversions}
    321353\CFA defines situations where values of one type are automatically converted to another type.
    322 These conversions are called \define{implicit conversion}s. The programmer can request
     354These conversions are called \define{implicit conversion}s.
     355The programmer can request
    323356\define{explicit conversion}s using cast expressions.
    324357
    … …  
    330363\subsubsection{Safe arithmetic conversions}
    331364
    332 In C, a pattern of conversions known as the \define{usual arithmetic conversion}s is used with most
    333 binary arithmetic operators to convert the operands to a common type and determine the type of the
    334 operator's result. In \CFA, these conversions play a role in overload resolution, and
    335 collectively are called the \define{safe arithmetic conversion}s.
    336 
    337 Let \(int_r\) and \(unsigned_r\) be the signed and unsigned integer types with integer conversion
    338 rank\index{integer conversion rank}\index{rank|see{integer conversion rank}} $r$. Let
    339 \(unsigned_{mr}\) be the unsigned integer type with maximal rank.
     365In C, a pattern of conversions known as the \define{usual arithmetic conversion}s is used with most binary arithmetic operators to convert the operands to a common type and determine the type of the operator's result.
     366In \CFA, these conversions play a role in overload resolution, and collectively are called the \define{safe arithmetic conversion}s.
     367
     368Let \(int_r\) and \(unsigned_r\) be the signed and unsigned integer types with integer conversion rank\index{integer conversion rank}\index{rank|see{integer conversion rank}} $r$.
     369Let \(unsigned_{mr}\) be the unsigned integer type with maximal rank.
    340370
    341371The following conversions are \emph{direct} safe arithmetic conversions.
    … …  
    343373\item
    344374The \Index{integer promotion}s.
    345 
    346 \item
    347 For every rank $r$ greater than or equal to the rank of \lstinline$int$, conversion from \(int_r\)
    348 to \(unsigned_r\).
    349 
    350 \item
    351 For every rank $r$ greater than or equal to the rank of \lstinline$int$, where \(int_{r+1}\) exists
    352 and can represent all values of \(unsigned_r\), conversion from \(unsigned_r\) to \(int_{r+1}\).
    353 
     375\item
     376For every rank $r$ greater than or equal to the rank of \lstinline$int$, conversion from \(int_r\) to \(unsigned_r\).
     377\item
     378For every rank $r$ greater than or equal to the rank of \lstinline$int$, where \(int_{r+1}\) exists and can represent all values of \(unsigned_r\), conversion from \(unsigned_r\) to \(int_{r+1}\).
    354379\item
    355380Conversion from \(unsigned_{mr}\) to \lstinline$float$.
    356 
    357381\item
    358382Conversion from an enumerated type to its compatible integer type.
    359 
    360 \item
    361 Conversion from \lstinline$float$ to \lstinline$double$, and from \lstinline$double$ to
    362 \lstinline$long double$.
    363 
    364 \item
    365 Conversion from \lstinline$float _Complex$ to \lstinline$double _Complex$,
    366 and from \lstinline$double _Complex$ to \lstinline$long double _Complex$.
    367 
     383\item
     384Conversion from \lstinline$float$ to \lstinline$double$, and from \lstinline$double$ to \lstinline$long double$.
     385\item
     386Conversion from \lstinline$float _Complex$ to \lstinline$double _Complex$, and from \lstinline$double _Complex$ to \lstinline$long double _Complex$.
    368387\begin{sloppypar}
    369388\item
    370 Conversion from \lstinline$float _Imaginary$ to \lstinline$double _Imaginary$, and from
    371 \lstinline$double _Imaginary$ to \lstinline$long double$ \lstinline$_Imaginary$, if the
    372 implementation supports imaginary types.
     389Conversion from \lstinline$float _Imaginary$ to \lstinline$double _Imaginary$, and from \lstinline$double _Imaginary$ to \lstinline$long double$ \lstinline$_Imaginary$, if the implementation supports imaginary types.
    373390\end{sloppypar}
    374391\end{itemize}
    375392
    376 If type \lstinline$T$ can be converted to type \lstinline$U$ by a safe direct arithmetic conversion
    377 and type \lstinline$U$ can be converted to type \lstinline$V$ by a safe arithmetic conversion, then
    378 the conversion from \lstinline$T$ to type \lstinline$V$ is an \emph{indirect} safe arithmetic
    379 conversion.
    380 
    381 \begin{rationale}
    382 Note that {\c11} does not include conversion from \Index{real type}s to \Index{complex type}s in the
    383 usual arithmetic conversions, and \CFA does not include them as safe conversions.
     393If type \lstinline$T$ can be converted to type \lstinline$U$ by a safe direct arithmetic conversion and type \lstinline$U$ can be converted to type \lstinline$V$ by a safe arithmetic conversion, then the conversion from \lstinline$T$ to type \lstinline$V$ is an \emph{indirect} safe arithmetic conversion.
     394
     395\begin{rationale}
     396Note that {\c11} does not include conversion from \Index{real type}s to \Index{complex type}s in the usual arithmetic conversions, and \CFA does not include them as safe conversions.
    384397\end{rationale}
    385398
    … …  
    393406
    394407If an expression's type is a pointer to a structure or union type that has a member that is an
    395 \Index{anonymous structure} or an \Index{anonymous union}, it can be implicitly
    396 converted\index{implicit conversion} to a pointer to the anonymous structure's or anonymous union's
    397 type. The result of the conversion is a pointer to the member.
     408\Index{anonymous structure} or an \Index{anonymous union}, it can be implicitly converted\index{implicit conversion} to a pointer to the anonymous structure's or anonymous union's type.
     409The result of the conversion is a pointer to the member.
    398410
    399411\examples
    … …  
    402414        int x, y;
    403415};
    404 void move_by(struct point * p1, struct point * p2) {@\impl{move_by}@
     416void move_by( struct point * p1, struct point * p2 ) {@\impl{move_by}@
    405417        p1->x += p2.x;
    406418        p1->y += p2.y;
    407419}
    408 
    409420struct color_point {
    410421        enum { RED, BLUE, GREEN } color;
    411422        struct point;
    412423} cp1, cp2;
    413 move_to(&cp1, &cp2);
     424move_to( &cp1, &cp2 );
    414425\end{lstlisting}
    415426Thanks to implicit conversion, the two arguments that \lstinline$move_by()$ receives are pointers to
    … …  
    418429
    419430\subsubsection{Specialization}
    420 A function or value whose type is polymorphic may be implicitly converted to one whose type is
    421 \Index{less polymorphic} by binding values to one or more of its \Index{inferred parameter}. Any
    422 value that is legal for the inferred parameter may be used, including other inferred parameters.
    423 
    424 If, after the inferred parameter binding, an \Index{assertion parameter} has no inferred parameters
    425 in its type, then an object or function must be visible at the point of the specialization that has
    426 the same identifier as the assertion parameter and has a type that is compatible\index{compatible
    427   type} with or can be specialized to the type of the assertion parameter.  The assertion parameter
    428 is bound to that object or function.
    429 
    430 The type of the specialization is the type of the original with the bound inferred parameters and
    431 the bound assertion parameters replaced by their bound values.
     431A function or value whose type is polymorphic may be implicitly converted to one whose type is \Index{less polymorphic} by binding values to one or more of its \Index{inferred parameter}.
     432Any value that is legal for the inferred parameter may be used, including other inferred parameters.
     433
     434If, after the inferred parameter binding, an \Index{assertion parameter} has no inferred parameters in its type, then an object or function must be visible at the point of the specialization that has the same identifier as the assertion parameter and has a type that is compatible\index{compatible type} with or can be specialized to the type of the assertion parameter.
     435The assertion parameter is bound to that object or function.
     436
     437The type of the specialization is the type of the original with the bound inferred parameters and the bound assertion parameters replaced by their bound values.
    432438
    433439\examples
    434440The type
    435441\begin{lstlisting}
    436 forall( type T, type U ) void (*)( T, U );
     442forall( otype T, otype U ) void (*)( T, U );
    437443\end{lstlisting}
    438444can be specialized to (among other things)
    439445\begin{lstlisting}
    440 forall( type T ) void (*)( T, T );              // U bound to T
    441 forall( type T ) void (*)( T, real );   // U bound to real
    442 forall( type U ) void (*)( real, U );   // T bound to real
     446forall( otype T ) void (*)( T, T );             // U bound to T
     447forall( otype T ) void (*)( T, real );  // U bound to real
     448forall( otype U ) void (*)( real, U );  // T bound to real
    443449void f( real, real );                                   // both bound to real
    444450\end{lstlisting}
    … …  
    446452The type
    447453\begin{lstlisting}
    448 forall( type T | T ?+?( T, T )) T (*)( T );
     454forall( otype T | T ?+?( T, T ) ) T (*)( T );
    449455\end{lstlisting}
    450456can be specialized to (among other things)
    451457\begin{lstlisting}
    452 int (*)( int );                                         // T bound to int, and T ?+?(T, T ) bound to int ?+?( int, int )
     458int (*)( int );         // T bound to int, and T ?+?(T, T ) bound to int ?+?( int, int )
    453459\end{lstlisting}
    454460
    … …  
    465471from a pointer to any non-\lstinline$void$ type to a pointer to \lstinline$void$;
    466472\item
    467 from a pointer to any type to a pointer to a more qualified version of the type\index{qualified
    468 type};
    469 \item
    470 from a pointer to a structure or union type to a pointer to the type of a member of the structure or
    471 union that is an \Index{anonymous structure} or an \Index{anonymous union};
    472 \item
    473 within the scope of an initialized \Index{type declaration}, conversions between a type and its
    474 implementation or between a pointer to a type and a pointer to its implementation.
     473from a pointer to any type to a pointer to a more qualified version of the type\index{qualified type};
     474\item
     475from a pointer to a structure or union type to a pointer to the type of a member of the structure or union that is an \Index{anonymous structure} or an \Index{anonymous union};
     476\item
     477within the scope of an initialized \Index{type declaration}, conversions between a type and its implementation or between a pointer to a type and a pointer to its implementation.
    475478\end{itemize}
    476479
    477480Conversions that are not safe conversions are \define{unsafe conversion}s.
    478481\begin{rationale}
    479 As in C, there is an implicit conversion from \lstinline$void *$ to any pointer type. This is
    480 clearly dangerous, and {\CC} does not have this implicit conversion.
    481 \CFA\index{deficiencies!void * conversion} keeps it, in the interest of remaining as pure a
    482 superset of C as possible, but discourages it by making it unsafe.
     482As in C, there is an implicit conversion from \lstinline$void *$ to any pointer type.
     483This is clearly dangerous, and {\CC} does not have this implicit conversion.
     484\CFA\index{deficiencies!void * conversion} keeps it, in the interest of remaining as pure a superset of C as possible, but discourages it by making it unsafe.
    483485\end{rationale}
    484486
    … …  
    486488\subsection{Conversion cost}
    487489
    488 The \define{conversion cost} of a safe\index{safe conversion}
    489 conversion\footnote{Unsafe\index{unsafe conversion} conversions do not have defined conversion
    490 costs.} is a measure of how desirable or undesirable it is. It is defined as follows.
     490The \define{conversion cost} of a safe\index{safe conversion} conversion\footnote{Unsafe\index{unsafe conversion} conversions do not have defined conversion costs.} is a measure of how desirable or undesirable it is.
     491It is defined as follows.
    491492\begin{itemize}
    492493\item
    … …  
    497498
    498499\item
    499 The cost of an indirect safe arithmetic conversion is the smallest number of direct conversions
    500 needed to make up the conversion.
     500The cost of an indirect safe arithmetic conversion is the smallest number of direct conversions needed to make up the conversion.
    501501\end{itemize}
    502502
    … …  
    506506\begin{itemize}
    507507\item
    508 The cost of an implicit conversion from \lstinline$int$ to \lstinline$long$ is 1. The cost of an
    509 implicit conversion from \lstinline$long$ to \lstinline$double$ is 3, because it is defined in terms
    510 of conversions from \lstinline$long$ to \lstinline$unsigned long$, then to \lstinline$float$, and
    511 then to \lstinline$double$.
    512 
    513 \item
    514 If \lstinline$int$ can represent all the values of \lstinline$unsigned short$, then the cost of an
    515 implicit conversion from \lstinline$unsigned short$ to \lstinline$unsigned$ is 2:
    516 \lstinline$unsigned short$ to \lstinline$int$ to \lstinline$unsigned$. Otherwise,
    517 \lstinline$unsigned short$ is converted directly to \lstinline$unsigned$, and the cost is 1.
    518 
    519 \item
    520 If \lstinline$long$ can represent all the values of \lstinline$unsigned$, then the conversion cost
    521 of \lstinline$unsigned$ to \lstinline$long$ is 1. Otherwise, the conversion is an unsafe
    522 conversion, and its conversion cost is undefined.
     508The cost of an implicit conversion from \lstinline$int$ to \lstinline$long$ is 1.
     509The cost of an implicit conversion from \lstinline$long$ to \lstinline$double$ is 3, because it is defined in terms of conversions from \lstinline$long$ to \lstinline$unsigned long$, then to \lstinline$float$, and then to \lstinline$double$.
     510
     511\item
     512If \lstinline$int$ can represent all the values of \lstinline$unsigned short$, then the cost of an implicit conversion from \lstinline$unsigned short$ to \lstinline$unsigned$ is 2:
     513\lstinline$unsigned short$ to \lstinline$int$ to \lstinline$unsigned$.
     514Otherwise, \lstinline$unsigned short$ is converted directly to \lstinline$unsigned$, and the cost is 1.
     515
     516\item
     517If \lstinline$long$ can represent all the values of \lstinline$unsigned$, then the conversion cost of \lstinline$unsigned$ to \lstinline$long$ is 1.
     518Otherwise, the conversion is an unsafe conversion, and its conversion cost is undefined.
    523519\end{itemize}
    524520
    … …  
    529525        \rhs \lstinline$forall$
    530526        \rhs \lstinline$lvalue$
    531         \rhs \lstinline$context$
     527        \rhs \lstinline$trait$
    532528        \rhs \lstinline$dtype$
    533529        \rhs \lstinline$ftype$
    … …  
    538534\subsection{Identifiers}
    539535
    540 \CFA allows operator \Index{overloading} by associating operators with special function
    541 identifiers. Furthermore, the constants ``\lstinline$0$'' and ``\lstinline$1$'' have special status
    542 for many of C's data types (and for many programmer-defined data types as well), so \CFA treats them
    543 as overloadable identifiers. Programmers can use these identifiers to declare functions and objects
    544 that implement operators and constants for their own types.
     536\CFA allows operator \Index{overloading} by associating operators with special function identifiers.
     537Furthermore, the constants ``\lstinline$0$'' and ``\lstinline$1$'' have special status for many of C's data types (and for many programmer-defined data types as well), so \CFA treats them as overloadable identifiers.
     538Programmers can use these identifiers to declare functions and objects that implement operators and constants for their own types.
    545539
    546540
    … …  
    554548\end{syntax}
    555549
    556 \index{constant identifiers}\index{identifiers!for constants} The tokens ``\lstinline$0$''\impl{0}
    557 and ``\lstinline$1$''\impl{1} are identifiers. No other tokens defined by the rules for integer
    558 constants are considered to be identifiers.
    559 \begin{rationale}
    560 Why ``\lstinline$0$'' and ``\lstinline$1$''? Those integers have special status in C. All scalar
    561 types can be incremented and decremented, which is defined in terms of adding or subtracting 1. The
    562 operations ``\lstinline$&&$'', ``\lstinline$||$'', and ``\lstinline$!$'' can be applied to any
    563 scalar arguments, and are defined in terms of comparison against 0. A \nonterm{constant-expression}
    564 that evaluates to 0 is effectively compatible with every pointer type.
    565 
    566 In C, the integer constants 0 and 1 suffice because the integer promotion rules can convert them to
    567 any arithmetic type, and the rules for pointer expressions treat constant expressions evaluating to
    568 0 as a special case. However, user-defined arithmetic types often need the equivalent of a 1 or 0
    569 for their functions or operators, polymorphic functions often need 0 and 1 constants of a type
    570 matching their polymorphic parameters, and user-defined pointer-like types may need a null value.
    571 Defining special constants for a user-defined type is more efficient than defining a conversion to
    572 the type from \lstinline$_Bool$.
    573 
    574 Why \emph{just} ``\lstinline$0$'' and ``\lstinline$1$''? Why not other integers? No other integers
    575 have special status in C. A facility that let programmers declare specific
    576 constants---``\lstinline$const Rational 12$'', for instance---would not be much of an improvement.
    577 Some facility for defining the creation of values of programmer-defined types from arbitrary integer
    578 tokens would be needed. The complexity of such a feature doesn't seem worth the gain.
     550\index{constant identifiers}\index{identifiers!for constants} The tokens ``\lstinline$0$''\impl{0} and ``\lstinline$1$''\impl{1} are identifiers.
     551No other tokens defined by the rules for integer constants are considered to be identifiers.
     552\begin{rationale}
     553Why ``\lstinline$0$'' and ``\lstinline$1$''? Those integers have special status in C.
     554All scalar types can be incremented and decremented, which is defined in terms of adding or subtracting 1.
     555The operations ``\lstinline$&&$'', ``\lstinline$||$'', and ``\lstinline$!$'' can be applied to any scalar arguments, and are defined in terms of comparison against 0.
     556A \nonterm{constant-expression} that evaluates to 0 is effectively compatible with every pointer type.
     557
     558In C, the integer constants 0 and 1 suffice because the integer promotion rules can convert them to any arithmetic type, and the rules for pointer expressions treat constant expressions evaluating to 0 as a special case.
     559However, user-defined arithmetic types often need the equivalent of a 1 or 0 for their functions or operators, polymorphic functions often need 0 and 1 constants of a type matching their polymorphic parameters, and user-defined pointer-like types may need a null value.
     560Defining special constants for a user-defined type is more efficient than defining a conversion to the type from \lstinline$_Bool$.
     561
     562Why \emph{just} ``\lstinline$0$'' and ``\lstinline$1$''? Why not other integers? No other integers have special status in C.
     563A facility that let programmers declare specific constants---``\lstinline$const Rational 12$'', for instance---would not be much of an improvement.
     564Some facility for defining the creation of values of programmer-defined types from arbitrary integer tokens would be needed.
     565The complexity of such a feature doesn't seem worth the gain.
    579566\end{rationale}
    580567
    … …  
    582569\subsubsection{Operator identifiers}
    583570
    584 \index{operator identifiers}\index{identifiers!for operators} Table \ref{opids} lists the
    585 programmer-definable operator identifiers and the operations they are associated with. Functions
    586 that are declared with (or pointed at by function pointers that are declared with) these identifiers
    587 can be called by expressions that use the operator tokens and syntax, or the operator identifiers
    588 and ``function call'' syntax. The relationships between operators and function calls are discussed
    589 in descriptions of the operators.
     571\index{operator identifiers}\index{identifiers!for operators} Table \ref{opids} lists the programmer-definable operator identifiers and the operations they are associated with.
     572Functions that are declared with (or pointed at by function pointers that are declared with) these identifiers can be called by expressions that use the operator tokens and syntax, or the operator identifiers and ``function call'' syntax.
     573The relationships between operators and function calls are discussed in descriptions of the operators.
    590574
    591575\begin{table}[hbt]
    … …  
    644628
    645629\begin{rationale}
    646 Operator identifiers are made up of the characters of the operator token, with question marks added
    647 to mark the positions of the arguments of operators. The question marks serve as mnemonic devices;
    648 programmers can not create new operators by arbitrarily mixing question marks and other
    649 non-alphabetic characters. Note that prefix and postfix versions of the increment and decrement
    650 operators are distinguished by the position of the question mark.
    651 \end{rationale}
    652 
    653 \begin{rationale}
    654 The use of ``\lstinline$?$'' in identifiers means that some C programs are not \CFA programs.  For
    655 instance, the sequence of characters ``\lstinline$(i < 0)?--i:i$'' is legal in a C program, but a
    656 \CFA compiler detects a syntax error because it treats ``\lstinline$?--$'' as an identifier, not
    657 as the two tokens ``\lstinline$?$'' and ``\lstinline$--$''.
     630Operator identifiers are made up of the characters of the operator token, with question marks added to mark the positions of the arguments of operators.
     631The question marks serve as mnemonic devices;
     632programmers can not create new operators by arbitrarily mixing question marks and other non-alphabetic characters.
     633Note that prefix and postfix versions of the increment and decrement operators are distinguished by the position of the question mark.
     634\end{rationale}
     635
     636\begin{rationale}
     637The use of ``\lstinline$?$'' in identifiers means that some C programs are not \CFA programs.  For instance, the sequence of characters ``\lstinline$(i < 0)?--i:i$'' is legal in a C program, but a
     638\CFA compiler detects a syntax error because it treats ``\lstinline$?--$'' as an identifier, not as the two tokens ``\lstinline$?$'' and ``\lstinline$--$''.
    658639\end{rationale}
    659640
    … …  
    663644\item
    664645The logical operators ``\lstinline$&&$'' and ``\lstinline$||$'', and the conditional operator
    665 ``\lstinline$?:$''. These operators do not always evaluate their operands, and hence can not be
    666 properly defined by functions unless some mechanism like call-by-name is added to the language.
    667 Note that the definitions of ``\lstinline$&&$'' and ``\lstinline$||$'' say that they work by
    668 checking that their arguments are unequal to 0, so defining ``\lstinline$!=$'' and ``\lstinline$0$''
    669 for user-defined types is enough to allow them to be used in logical expressions.
    670 
    671 \item
    672 The comma operator\index{comma expression}. It is a control-flow operator like those above.
     646``\lstinline$?:$''.
     647These operators do not always evaluate their operands, and hence can not be properly defined by functions unless some mechanism like call-by-name is added to the language.
     648Note that the definitions of ``\lstinline$&&$'' and ``\lstinline$||$'' say that they work by checking that their arguments are unequal to 0, so defining ``\lstinline$!=$'' and ``\lstinline$0$'' for user-defined types is enough to allow them to be used in logical expressions.
     649
     650\item
     651The comma operator\index{comma expression}.
     652It is a control-flow operator like those above.
    673653Changing its meaning seems pointless and confusing.
    674654
    675655\item
    676 The ``address of'' operator. It would seem useful to define a unary ``\lstinline$&$'' operator that
    677 returns values of some programmer-defined pointer-like type. The problem lies with the type of the
    678 operator. Consider the expression ``\lstinline$p = &x$'', where \lstinline$x$ is of type
    679 \lstinline$T$ and \lstinline$p$ has the programmer-defined type \lstinline$T_ptr$. The expression
    680 might be treated as a call to the unary function ``\lstinline$&?$''. Now what is the type of the
    681 function's parameter? It can not be \lstinline$T$, because then \lstinline$x$ would be passed by
    682 value, and there is no way to create a useful pointer-like result from a value. Hence the parameter
    683 must have type \lstinline$T *$. But then the expression must be rewritten as ``\lstinline$p = &?( &x )$''
     656The ``address of'' operator.
     657It would seem useful to define a unary ``\lstinline$&$'' operator that returns values of some programmer-defined pointer-like type.
     658The problem lies with the type of the operator.
     659Consider the expression ``\lstinline$p = &x$'', where \lstinline$x$ is of type
     660\lstinline$T$ and \lstinline$p$ has the programmer-defined type \lstinline$T_ptr$.
     661The expression might be treated as a call to the unary function ``\lstinline$&?$''.
     662Now what is the type of the function's parameter? It can not be \lstinline$T$, because then \lstinline$x$ would be passed by value, and there is no way to create a useful pointer-like result from a value.
     663Hence the parameter must have type \lstinline$T *$.
     664But then the expression must be rewritten as ``\lstinline$p = &?( &x )$''
    684665---which doesn't seem like progress!
    685666
    686 The rule for address-of expressions would have to be something like ``keep applying address-of
    687 functions until you get one that takes a pointer argument, then use the built-in operator and
    688 stop''. It seems simpler to define a conversion function from \lstinline$T *$ to \lstinline$T_ptr$.
    689 
    690 \item
    691 The \lstinline$sizeof$ operator. It is already defined for every object type, and intimately tied
    692 into the language's storage allocation model. Redefining it seems pointless.
    693 
    694 \item
    695 The ``member of'' operators ``\lstinline$.$'' and ``\lstinline$->$''. These are not really infix
    696 operators, since their right ``operand'' is not a value or object.
    697 
    698 \item
    699 Cast operators\index{cast expression}. Anything that can be done with an explicit cast can be done
    700 with a function call. The difference in syntax is small.
     667The rule for address-of expressions would have to be something like ``keep applying address-of functions until you get one that takes a pointer argument, then use the built-in operator and stop''.
     668It seems simpler to define a conversion function from \lstinline$T *$ to \lstinline$T_ptr$.
     669
     670\item
     671The \lstinline$sizeof$ operator.
     672It is already defined for every object type, and intimately tied into the language's storage allocation model.
     673Redefining it seems pointless.
     674
     675\item
     676The ``member of'' operators ``\lstinline$.$'' and ``\lstinline$->$''.
     677These are not really infix operators, since their right ``operand'' is not a value or object.
     678
     679\item
     680Cast operators\index{cast expression}.
     681Anything that can be done with an explicit cast can be done with a function call.
     682The difference in syntax is small.
    701683\end{itemize}
    702684\end{rationale}
    … …  
    705687\section{Expressions}
    706688
    707 \CFA allows operators and identifiers to be overloaded. Hence, each expression can have a number
    708 of \define{interpretation}s, each of which has a different type. The interpretations that are
    709 potentially executable are called \define{valid interpretation}s. The set of interpretations
    710 depends on the kind of expression and on the interpretations of the subexpressions that it contains.
    711 The rules for determining the valid interpretations of an expression are discussed below for each
    712 kind of expression. Eventually the context of the outermost expression chooses one interpretation
    713 of that expression.
    714 
    715 An \define{ambiguous interpretation} is an interpretation which does not specify the exact object or
    716 function denoted by every identifier in the expression. An expression can have some interpretations
    717 that are ambiguous and others that are unambiguous. An expression that is chosen to be executed
    718 shall not be ambiguous.
    719 
    720 The \define{best valid interpretations} are the valid interpretations that use the fewest
    721 unsafe\index{unsafe conversion} conversions. Of these, the best are those where the functions and
    722 objects involved are the least polymorphic\index{less polymorphic}. Of these, the best have the
    723 lowest total \Index{conversion cost}, including all implicit conversions in the argument
    724 expressions. Of these, the best have the highest total conversion cost for the implicit conversions
    725 (if any) applied to the argument expressions. If there is no single best valid interpretation, or if
    726 the best valid interpretation is ambiguous, then the resulting interpretation is
    727 ambiguous\index{ambiguous interpretation}.
    728 
    729 \begin{rationale}
    730 \CFA's rules for selecting the best interpretation are designed to allow overload resolution to
    731 mimic C's operator semantics. In C, the ``usual arithmetic conversions'' are applied to the
    732 operands of binary operators if necessary to convert the operands to types with a common real type.
    733 In \CFA, those conversions are ``safe''. The ``fewest unsafe conversions'' rule ensures that the
    734 usual conversions are done, if possible. The ``lowest total expression cost'' rule chooses the
    735 proper common type. The odd-looking ``highest argument conversion cost'' rule ensures that, when
    736 unary expressions must be converted, conversions of function results are preferred to conversion of
    737 function arguments: \lstinline$(double)-i$ will be preferred to \lstinline$-(double)i$.
    738 
    739 The ``least polymorphic'' rule reduces the number of polymorphic function calls, since such
    740 functions are presumably more expensive than monomorphic functions and since the more specific
    741 function is presumably more appropriate. It also gives preference to monomorphic values (such as the
     689\CFA allows operators and identifiers to be overloaded.
     690Hence, each expression can have a number of \define{interpretation}s, each of which has a different type.
     691The interpretations that are potentially executable are called \define{valid interpretation}s.
     692The set of interpretations depends on the kind of expression and on the interpretations of the subexpressions that it contains.
     693The rules for determining the valid interpretations of an expression are discussed below for each kind of expression.
     694Eventually the context of the outermost expression chooses one interpretation of that expression.
     695
     696An \define{ambiguous interpretation} is an interpretation which does not specify the exact object or function denoted by every identifier in the expression.
     697An expression can have some interpretations that are ambiguous and others that are unambiguous.
     698An expression that is chosen to be executed shall not be ambiguous.
     699
     700The \define{best valid interpretations} are the valid interpretations that use the fewest unsafe\index{unsafe conversion} conversions.
     701Of these, the best are those where the functions and objects involved are the least polymorphic\index{less polymorphic}.
     702Of these, the best have the lowest total \Index{conversion cost}, including all implicit conversions in the argument expressions.
     703Of these, the best have the highest total conversion cost for the implicit conversions
     704(if any) applied to the argument expressions.
     705If there is no single best valid interpretation, or if the best valid interpretation is ambiguous, then the resulting interpretation is ambiguous\index{ambiguous interpretation}.
     706
     707\begin{rationale}
     708\CFA's rules for selecting the best interpretation are designed to allow overload resolution to mimic C's operator semantics.
     709In C, the ``usual arithmetic conversions'' are applied to the operands of binary operators if necessary to convert the operands to types with a common real type.
     710In \CFA, those conversions are ``safe''.
     711The ``fewest unsafe conversions'' rule ensures that the usual conversions are done, if possible.
     712The ``lowest total expression cost'' rule chooses the proper common type.
     713The odd-looking ``highest argument conversion cost'' rule ensures that, when unary expressions must be converted, conversions of function results are preferred to conversion of function arguments: \lstinline$(double)-i$ will be preferred to \lstinline$-(double)i$.
     714
     715The ``least polymorphic'' rule reduces the number of polymorphic function calls, since such functions are presumably more expensive than monomorphic functions and since the more specific function is presumably more appropriate.
     716It also gives preference to monomorphic values (such as the
    742717\lstinline$int$ \lstinline$0$) over polymorphic values (such as the \Index{null pointer}
    743 \lstinline$0$\use{0}). However, interpretations that call polymorphic functions are preferred to
    744 interpretations that perform unsafe conversions, because those conversions potentially lose accuracy
    745 or violate strong typing.
     718\lstinline$0$\use{0}).
     719However, interpretations that call polymorphic functions are preferred to interpretations that perform unsafe conversions, because those conversions potentially lose accuracy or violate strong typing.
    746720
    747721There are two notable differences between \CFA's overload resolution rules and the rules for
    748 {\CC} defined in \cite{c++}. First, the result type of a function plays a role. In {\CC}, a
    749 function call must be completely resolved based on the arguments to the call in most circumstances.
    750 In \CFA, a function call may have several interpretations, each with a different result type, and
    751 the interpretations of the containing context choose among them. Second, safe conversions are used
    752 to choose among interpretations of all sorts of functions; in {\CC}, the ``usual arithmetic
    753 conversions'' are a separate set of rules that apply only to the built-in operators.
    754 \end{rationale}
    755 
    756 Expressions involving certain operators\index{operator identifiers} are considered to be equivalent
    757 to function calls. A transformation from ``operator'' syntax to ``function call'' syntax is defined
    758 by \define{rewrite rules}. Each operator has a set of predefined functions that overload its
    759 identifier. Overload resolution determines which member of the set is executed in a given
    760 expression. The functions have \Index{internal linkage} and are implicitly declared with \Index{file
    761 scope}. The predefined functions and rewrite rules are discussed below for each of these
    762 operators.
    763 \begin{rationale}
    764 Predefined functions and constants have internal linkage because that simplifies optimization in
    765 traditional compile-and-link environments. For instance, ``\lstinline$an_int + an_int$'' is
    766 equivalent to ``\lstinline$?+?(an_int, an_int)$''. If integer addition has not been redefined in
    767 the current scope, a compiler can generate code to perform the addition directly. If predefined
    768 functions had external linkage, this optimization would be difficult.
    769 \end{rationale}
    770 
    771 \begin{rationale}
    772 Since each subsection describes the interpretations of an expression in terms of the interpretations
    773 of its subexpressions, this chapter can be taken as describing an overload resolution algorithm that
    774 uses one bottom-up pass over an expression tree. Such an algorithm was first described (for Ada) by
    775 Baker~\cite{Bak:overload}. It is extended here to handle polymorphic functions and arithmetic
    776 conversions. The overload resolution rules and the predefined functions have been chosen so that, in
    777 programs that do not introduce overloaded declarations, expressions will have the same meaning in C
    778 and in \CFA.
    779 \end{rationale}
    780 
    781 \begin{rationale}
    782 Expression syntax is quoted from the {\c11} standard. The syntax itself defines the precedence and
    783 associativity of operators. The sections are arranged in decreasing order of precedence, with all
    784 operators in a section having the same precedence.
     722{\CC} defined in \cite{c++}.
     723First, the result type of a function plays a role.
     724In {\CC}, a function call must be completely resolved based on the arguments to the call in most circumstances.
     725In \CFA, a function call may have several interpretations, each with a different result type, and the interpretations of the containing context choose among them.
     726Second, safe conversions are used to choose among interpretations of all sorts of functions;
     727in {\CC}, the ``usual arithmetic conversions'' are a separate set of rules that apply only to the built-in operators.
     728\end{rationale}
     729
     730Expressions involving certain operators\index{operator identifiers} are considered to be equivalent to function calls.
     731A transformation from ``operator'' syntax to ``function call'' syntax is defined by \define{rewrite rules}.
     732Each operator has a set of predefined functions that overload its identifier.
     733Overload resolution determines which member of the set is executed in a given expression.
     734The functions have \Index{internal linkage} and are implicitly declared with \Index{file scope}.
     735The predefined functions and rewrite rules are discussed below for each of these operators.
     736\begin{rationale}
     737Predefined functions and constants have internal linkage because that simplifies optimization in traditional compile-and-link environments.
     738For instance, ``\lstinline$an_int + an_int$'' is equivalent to ``\lstinline$?+?(an_int, an_int)$''.
     739If integer addition has not been redefined in the current scope, a compiler can generate code to perform the addition directly.
     740If predefined functions had external linkage, this optimization would be difficult.
     741\end{rationale}
     742
     743\begin{rationale}
     744Since each subsection describes the interpretations of an expression in terms of the interpretations of its subexpressions, this chapter can be taken as describing an overload resolution algorithm that uses one bottom-up pass over an expression tree.
     745Such an algorithm was first described (for Ada) by Baker~\cite{Bak:overload}.
     746It is extended here to handle polymorphic functions and arithmetic conversions.
     747The overload resolution rules and the predefined functions have been chosen so that, in programs that do not introduce overloaded declarations, expressions will have the same meaning in C and in \CFA.
     748\end{rationale}
     749
     750\begin{rationale}
     751Expression syntax is quoted from the {\c11} standard.
     752The syntax itself defines the precedence and associativity of operators.
     753The sections are arranged in decreasing order of precedence, with all operators in a section having the same precedence.
    785754\end{rationale}
    786755
    … …  
    801770const int 1;@\use{1}@
    802771const int 0;@\use{0}@
    803 forall( dtype DT ) DT *const 0;
    804 forall( ftype FT ) FT *const 0;
     772forall( dtype DT ) DT * const 0;
     773forall( ftype FT ) FT * const 0;
    805774\end{lstlisting}
    806775
    807776\semantics
    808 The \Index{valid interpretation} of an \nonterm{identifier} are given by the visible\index{visible}
    809 declarations of the identifier.
    810 
    811 A \nonterm{constant} or \nonterm{string-literal} has one valid interpretation, which has the type
    812 and value defined by {\c11}. The predefined integer identifiers ``\lstinline$1$'' and
    813 ``\lstinline$0$'' have the integer values 1 and 0, respectively. The other two predefined
    814 ``\lstinline$0$'' identifiers are bound to polymorphic pointer values that, when
    815 specialized\index{specialization} with a data type or function type respectively, produce a null
    816 pointer of that type.
     777The \Index{valid interpretation} of an \nonterm{identifier} are given by the visible\index{visible} declarations of the identifier.
     778
     779A \nonterm{constant} or \nonterm{string-literal} has one valid interpretation, which has the type and value defined by {\c11}.
     780The predefined integer identifiers ``\lstinline$1$'' and ``\lstinline$0$'' have the integer values 1 and 0, respectively.
     781The other two predefined ``\lstinline$0$'' identifiers are bound to polymorphic pointer values that, when specialized\index{specialization} with a data type or function type respectively, produce a null pointer of that type.
    817782
    818783A parenthesised expression has the same interpretations as the contained \nonterm{expression}.
    819784
    820785\examples
    821 The expression \lstinline$(void *)0$\use{0} specializes the (polymorphic) null pointer to a null
    822 pointer to \lstinline$void$. \lstinline$(const void *)0$ does the same, and also uses a safe
    823 conversion from \lstinline$void *$ to \lstinline$const void *$. In each case, the null pointer
    824 conversion is better\index{best valid interpretations} than the unsafe conversion of the integer
     786The expression \lstinline$(void *)0$\use{0} specializes the (polymorphic) null pointer to a null pointer to \lstinline$void$. \lstinline$(const void *)0$ does the same, and also uses a safe conversion from \lstinline$void *$ to \lstinline$const void *$.
     787In each case, the null pointer conversion is better\index{best valid interpretations} than the unsafe conversion of the integer
    825788\lstinline$0$ to a pointer.
    826789
    … …  
    828791Note that the predefined identifiers have addresses.
    829792
    830 \CFA does not have C's concept of ``null pointer constants'', which are not typed values but
    831 special strings of tokens. The C token ``\lstinline$0$'' is an expression of type \lstinline$int$
    832 with the value ``zero'', and it \emph{also} is a null pointer constant. Similarly,
    833 ``\lstinline$(void *)0$ is an expression of type \lstinline$(void *)$ whose value is a null pointer,
    834 and it also is a null pointer constant. However, in C, ``\lstinline$(void *)(void *)0$'' is
    835 \emph{not} a null pointer constant, even though it is null-valued, a pointer, and constant! The
    836 semantics of C expressions contain many special cases to deal with subexpressions that are null
    837 pointer constants.
    838 
    839 \CFA handles these cases through overload resolution. The declaration
    840 \begin{lstlisting}
    841 forall( dtype DT ) DT *const 0;
    842 \end{lstlisting}
    843 means that \lstinline$0$ is a polymorphic object, and contains a value that can have \emph{any}
    844 pointer-to-object type or pointer-to-incomplete type. The only such value is the null pointer.
    845 Therefore the type \emph{alone} is enough to identify a null pointer. Where C defines an operator
    846 with a special case for the null pointer constant, \CFA defines predefined functions with a
    847 polymorphic object parameter.
     793\CFA does not have C's concept of ``null pointer constants'', which are not typed values but special strings of tokens.
     794The C token ``\lstinline$0$'' is an expression of type \lstinline$int$ with the value ``zero'', and it \emph{also} is a null pointer constant.
     795Similarly,
     796``\lstinline$(void *)0$ is an expression of type \lstinline$(void *)$ whose value is a null pointer, and it also is a null pointer constant.
     797However, in C, ``\lstinline$(void *)(void *)0$'' is
     798\emph{not} a null pointer constant, even though it is null-valued, a pointer, and constant! The semantics of C expressions contain many special cases to deal with subexpressions that are null pointer constants.
     799
     800\CFA handles these cases through overload resolution.
     801The declaration
     802\begin{lstlisting}
     803forall( dtype DT ) DT * const 0;
     804\end{lstlisting} means that \lstinline$0$ is a polymorphic object, and contains a value that can have \emph{any} pointer-to-object type or pointer-to-incomplete type.
     805The only such value is the null pointer.
     806Therefore the type \emph{alone} is enough to identify a null pointer.
     807Where C defines an operator with a special case for the null pointer constant, \CFA defines predefined functions with a polymorphic object parameter.
    848808\end{rationale}
    849809
    … …  
    851811\subsubsection{Generic selection}
    852812
    853 \constraints The best interpretation of the controlling expression shall be
    854 unambiguous\index{ambiguous interpretation}, and shall have type compatible with at most one of the
    855 types named in its generic association list. If a generic selection has no \lstinline$default$
    856 generic association, the best interpretation of its controlling expression shall have type
    857 compatible with exactly one of the types named in its generic association list.
     813\constraints The best interpretation of the controlling expression shall be unambiguous\index{ambiguous interpretation}, and shall have type compatible with at most one of the types named in its generic association list.
     814If a generic selection has no \lstinline$default$ generic association, the best interpretation of its controlling expression shall have type compatible with exactly one of the types named in its generic association list.
    858815
    859816\semantics
    … …  
    883840\rewriterules
    884841\begin{lstlisting}
    885 a[b] @\rewrite@ ?[?]( b, a ) // if a has integer type */@\use{?[?]}@
     842a[b] @\rewrite@ ?[?]( b, a ) // if a has integer type@\use{?[?]}@
    886843a[b] @\rewrite@ ?[?]( a, b ) // otherwise
    887 a( ${\em arguments }$ ) @\rewrite@ ?()( a, ${\em arguments} )$@\use{?()}@
     844a( @\emph{arguments}@ ) @\rewrite@ ?()( a, @\emph{arguments}@ )@\use{?()}@
    888845a++ @\rewrite@ ?++(&( a ))@\use{?++}@
    889846a-- @\rewrite@ ?--(&( a ))@\use{?--}@
    … …  
    895852\predefined
    896853\begin{lstlisting}
    897 forall( type T ) lvalue T ?[?]( T *, ptrdiff_t );@\use{ptrdiff_t}@
    898 forall( type T ) lvalue _Atomic T ?[?]( _Atomic T *, ptrdiff_t );
    899 forall( type T ) lvalue const T ?[?]( const T *, ptrdiff_t );
    900 forall( type T ) lvalue restrict T ?[?]( restrict T *, ptrdiff_t );
    901 forall( type T ) lvalue volatile T ?[?]( volatile T *, ptrdiff_t );
    902 forall( type T ) lvalue _Atomic const T ?[?]( _Atomic const T *, ptrdiff_t );
    903 forall( type T ) lvalue _Atomic restrict T ?[?]( _Atomic restrict T *, ptrdiff_t );
    904 forall( type T ) lvalue _Atomic volatile T ?[?]( _Atomic volatile T *, ptrdiff_t );
    905 forall( type T ) lvalue const restrict T ?[?]( const restrict T *, ptrdiff_t );
    906 forall( type T ) lvalue const volatile T ?[?]( const volatile T *, ptrdiff_t );
    907 forall( type T ) lvalue restrict volatile T ?[?]( restrict volatile T *, ptrdiff_t );
    908 forall( type T ) lvalue _Atomic const restrict T ?[?]( _Atomic const restrict T *, ptrdiff_t );
    909 forall( type T ) lvalue _Atomic const volatile T ?[?]( _Atomic const volatile T *, ptrdiff_t );
    910 forall( type T ) lvalue _Atomic restrict volatile T ?[?]( _Atomic restrict volatile T *, ptrdiff_t );
    911 forall( type T ) lvalue const restrict volatile T ?[?]( const restrict volatile T *, ptrdiff_t );
    912 forall( type T ) lvalue _Atomic const restrict volatile T ?[?]( _Atomic const restrict volatile T *, ptrdiff_t );
     854forall( otype T ) lvalue T ?[?]( T *, ptrdiff_t );@\use{ptrdiff_t}@
     855forall( otype T ) lvalue _Atomic T ?[?]( _Atomic T *, ptrdiff_t );
     856forall( otype T ) lvalue const T ?[?]( const T *, ptrdiff_t );
     857forall( otype T ) lvalue restrict T ?[?]( restrict T *, ptrdiff_t );
     858forall( otype T ) lvalue volatile T ?[?]( volatile T *, ptrdiff_t );
     859forall( otype T ) lvalue _Atomic const T ?[?]( _Atomic const T *, ptrdiff_t );
     860forall( otype T ) lvalue _Atomic restrict T ?[?]( _Atomic restrict T *, ptrdiff_t );
     861forall( otype T ) lvalue _Atomic volatile T ?[?]( _Atomic volatile T *, ptrdiff_t );
     862forall( otype T ) lvalue const restrict T ?[?]( const restrict T *, ptrdiff_t );
     863forall( otype T ) lvalue const volatile T ?[?]( const volatile T *, ptrdiff_t );
     864forall( otype T ) lvalue restrict volatile T ?[?]( restrict volatile T *, ptrdiff_t );
     865forall( otype T ) lvalue _Atomic const restrict T ?[?]( _Atomic const restrict T *, ptrdiff_t );
     866forall( otype T ) lvalue _Atomic const volatile T ?[?]( _Atomic const volatile T *, ptrdiff_t );
     867forall( otype T ) lvalue _Atomic restrict volatile T ?[?]( _Atomic restrict volatile T *, ptrdiff_t );
     868forall( otype T ) lvalue const restrict volatile T ?[?]( const restrict volatile T *, ptrdiff_t );
     869forall( otype T ) lvalue _Atomic const restrict volatile T ?[?]( _Atomic const restrict volatile T *, ptrdiff_t );
    913870\end{lstlisting}
    914871\semantics
    915 The interpretations of subscript expressions are the interpretations of the corresponding function
    916 call expressions.
     872The interpretations of subscript expressions are the interpretations of the corresponding function call expressions.
    917873\begin{rationale}
    918874C defines subscripting as pointer arithmetic in a way that makes \lstinline$a[i]$ and
    919 \lstinline$i[a]$ equivalent. \CFA provides the equivalence through a rewrite rule to reduce the
    920 number of overloadings of \lstinline$?[?]$.
    921 
    922 Subscript expressions are rewritten as function calls that pass the first parameter by value. This
    923 is somewhat unfortunate, since array-like types tend to be large. The alternative is to use the
    924 rewrite rule ``\lstinline$a[b]$ \rewrite \lstinline$?[?](&(a), b)$''. However, C semantics forbid
    925 this approach: the \lstinline$a$ in ``\lstinline$a[b]$'' can be an arbitrary pointer value, which
    926 does not have an address.
     875\lstinline$i[a]$ equivalent. \CFA provides the equivalence through a rewrite rule to reduce the number of overloadings of \lstinline$?[?]$.
     876
     877Subscript expressions are rewritten as function calls that pass the first parameter by value.
     878This is somewhat unfortunate, since array-like types tend to be large.
     879The alternative is to use the rewrite rule ``\lstinline$a[b]$ \rewrite \lstinline$?[?](&(a), b)$''.
     880However, C semantics forbid this approach: the \lstinline$a$ in ``\lstinline$a[b]$'' can be an arbitrary pointer value, which does not have an address.
    927881
    928882The repetitive form of the predefined identifiers shows up a deficiency\index{deficiencies!pointers
    929  to qualified types} of \CFA's type system. Type qualifiers are not included in type values, so
    930 polymorphic functions that take pointers to arbitrary types often come in one flavor for each
    931 possible qualification of the pointed-at type.
     883 to qualified types} of \CFA's type system.
     884Type qualifiers are not included in type values, so polymorphic functions that take pointers to arbitrary types often come in one flavor for each possible qualification of the pointed-at type.
    932885\end{rationale}
    933886
    … …  
    936889
    937890\semantics
    938 A \define{function designator} is an interpretation of an expression that has function type. The
    939 \nonterm{postfix-expression} in a function call may have some interpretations that are function
    940 designators and some that are not.
    941 
    942 For those interpretations of the \nonterm{postfix-expression} that are not function designators, the
    943 expression is rewritten and becomes a call of a function named ``\lstinline$?()$''. The valid
    944 interpretations of the rewritten expression are determined in the manner described below.
    945 
    946 Each combination of function designators and argument interpretations is considered. For those
    947 interpretations of the \nonterm{postfix-expression} that are \Index{monomorphic function}
    948 designators, the combination has a \Index{valid interpretation} if the function designator accepts
    949 the number of arguments given, and each argument interpretation matches the corresponding explicit
    950 parameter:
     891A \define{function designator} is an interpretation of an expression that has function type.
     892The
     893\nonterm{postfix-expression} in a function call may have some interpretations that are function designators and some that are not.
     894
     895For those interpretations of the \nonterm{postfix-expression} that are not function designators, the expression is rewritten and becomes a call of a function named ``\lstinline$?()$''.
     896The valid interpretations of the rewritten expression are determined in the manner described below.
     897
     898Each combination of function designators and argument interpretations is considered.
     899For those interpretations of the \nonterm{postfix-expression} that are \Index{monomorphic function} designators, the combination has a \Index{valid interpretation} if the function designator accepts the number of arguments given, and each argument interpretation matches the corresponding explicit parameter:
    951900\begin{itemize}
    952 \item
    953 if the argument corresponds to a parameter in the function designator's prototype, the argument
    954 interpretation must have the same type as the corresponding parameter, or be implicitly convertible
    955 to the parameter's type
    956 \item
    957 if the function designator's type does not include a prototype or if the argument corresponds to
     901\item if the argument corresponds to a parameter in the function designator's prototype, the argument interpretation must have the same type as the corresponding parameter, or be implicitly convertible to the parameter's type
     902\item if the function designator's type does not include a prototype or if the argument corresponds to
    958903``\lstinline$...$'' in a prototype, a \Index{default argument promotion} is applied to it.
    959904\end{itemize}
    … …  
    961906
    962907For those combinations where the interpretation of the \nonterm{postfix-expression} is a
    963 \Index{polymorphic function} designator and the function designator accepts the number of arguments
    964 given, there shall be at least one set of \define{implicit argument}s for the implicit parameters
    965 such that
     908\Index{polymorphic function} designator and the function designator accepts the number of arguments given, there shall be at least one set of \define{implicit argument}s for the implicit parameters such that
    966909\begin{itemize}
    967910\item
    968 If the declaration of the implicit parameter uses \Index{type-class} \lstinline$type$\use{type}, the
    969 implicit argument must be an object type; if it uses \lstinline$dtype$, the implicit argument must
    970 be an object type or an incomplete type; and if it uses \lstinline$ftype$, the implicit argument
    971 must be a function type.
    972 
    973 \item
    974 if an explicit parameter's type uses any implicit parameters, then the corresponding explicit
    975 argument must have a type that is (or can be safely converted\index{safe conversion} to) the type
    976 produced by substituting the implicit arguments for the implicit parameters in the explicit
    977 parameter type.
    978 
    979 \item
    980 the remaining explicit arguments must match the remaining explicit parameters, as described for
    981 monomorphic function designators.
    982 
    983 \item
    984 for each \Index{assertion parameter} in the function designator's type, there must be an object or
    985 function with the same identifier that is visible at the call site and whose type is compatible with
    986 or can be specialized to the type of the assertion declaration.
     911If the declaration of the implicit parameter uses \Index{type-class} \lstinline$type$\use{type}, the implicit argument must be an object type;
     912if it uses \lstinline$dtype$, the implicit argument must be an object type or an incomplete type;
     913and if it uses \lstinline$ftype$, the implicit argument must be a function type.
     914
     915\item if an explicit parameter's type uses any implicit parameters, then the corresponding explicit argument must have a type that is (or can be safely converted\index{safe conversion} to) the type produced by substituting the implicit arguments for the implicit parameters in the explicit parameter type.
     916
     917\item the remaining explicit arguments must match the remaining explicit parameters, as described for monomorphic function designators.
     918
     919\item for each \Index{assertion parameter} in the function designator's type, there must be an object or function with the same identifier that is visible at the call site and whose type is compatible with or can be specialized to the type of the assertion declaration.
    987920\end{itemize}
    988 There is a valid interpretation for each such set of implicit parameters. The type of each valid
    989 interpretation is the return type of the function designator with implicit parameter values
    990 substituted for the implicit arguments.
    991 
    992 A valid interpretation is ambiguous\index{ambiguous interpretation} if the function designator or
    993 any of the argument interpretations is ambiguous.
    994 
    995 Every valid interpretation whose return type is not compatible with any other valid interpretation's
    996 return type is an interpretation of the function call expression.
    997 
    998 Every set of valid interpretations that have mutually compatible\index{compatible type} result types
    999 also produces an interpretation of the function call expression. The type of the interpretation is
    1000 the \Index{composite type} of the types of the valid interpretations, and the value of the
    1001 interpretation is that of the \Index{best valid interpretation}.
    1002 \begin{rationale}
    1003 One desirable property of a polymorphic programming language is \define{generalizability}: the
    1004 ability to replace an abstraction with a more general but equivalent abstraction without requiring
    1005 changes in any of the uses of the original\cite{Cormack90}. For instance, it should be possible to
    1006 replace a function ``\lstinline$int f( int );$'' with ``\lstinline$forall( type T ) T f( T );$''
    1007 without affecting any calls of \lstinline$f$.
     921There is a valid interpretation for each such set of implicit parameters.
     922The type of each valid interpretation is the return type of the function designator with implicit parameter values substituted for the implicit arguments.
     923
     924A valid interpretation is ambiguous\index{ambiguous interpretation} if the function designator or any of the argument interpretations is ambiguous.
     925
     926Every valid interpretation whose return type is not compatible with any other valid interpretation's return type is an interpretation of the function call expression.
     927
     928Every set of valid interpretations that have mutually compatible\index{compatible type} result types also produces an interpretation of the function call expression.
     929The type of the interpretation is the \Index{composite type} of the types of the valid interpretations, and the value of the interpretation is that of the \Index{best valid interpretation}.
     930\begin{rationale}
     931One desirable property of a polymorphic programming language is \define{generalizability}: the ability to replace an abstraction with a more general but equivalent abstraction without requiring changes in any of the uses of the original\cite{Cormack90}.
     932For instance, it should be possible to replace a function ``\lstinline$int f( int );$'' with ``\lstinline$forall( otype T ) T f( T );$'' without affecting any calls of \lstinline$f$.
    1008933
    1009934\CFA\index{deficiencies!generalizability} does not fully possess this property, because
    … …  
    1015940float f;
    1016941double d;
    1017 f = g( f, f );  // (1)
    1018 f = g( i, f );  // (2) (safe conversion to float)
    1019 f = g( d, f );  // (3) (unsafe conversion to float)
    1020 \end{lstlisting}
    1021 If \lstinline$g$ was replaced by ``\lstinline$forall( type T ) T g( T, T );$'', the first and second
    1022 calls would be unaffected, but the third would change: \lstinline$f$ would be converted to
     942f = g( f, f );          // (1)
     943f = g( i, f );          // (2) (safe conversion to float)
     944f = g( d, f );          // (3) (unsafe conversion to float)
     945\end{lstlisting}
     946If \lstinline$g$ was replaced by ``\lstinline$forall( otype T ) T g( T, T );$'', the first and second calls would be unaffected, but the third would change: \lstinline$f$ would be converted to
    1023947\lstinline$double$, and the result would be a \lstinline$double$.
    1024948
    1025 Another example is the function ``\lstinline$void h( int *);$''. This function can be passed a
    1026 \lstinline$void *$ argument, but the generalization ``\lstinline$forall( type T ) void h( T *);$''
    1027 can not. In this case, \lstinline$void$ is not a valid value for \lstinline$T$ because it is not an
    1028 object type. If unsafe conversions were allowed, \lstinline$T$ could be inferred to be \emph{any}
    1029 object type, which is undesirable.
     949Another example is the function ``\lstinline$void h( int *);$''.
     950This function can be passed a
     951\lstinline$void *$ argument, but the generalization ``\lstinline$forall( otype T ) void h( T *);$'' can not.
     952In this case, \lstinline$void$ is not a valid value for \lstinline$T$ because it is not an object type.
     953If unsafe conversions were allowed, \lstinline$T$ could be inferred to be \emph{any} object type, which is undesirable.
    1030954\end{rationale}
    1031955
    … …  
    1033957A function called ``\lstinline$?()$'' might be part of a numerical differentiation package.
    1034958\begin{lstlisting}
    1035 extern type Derivative;
     959extern otype Derivative;
    1036960extern double ?()( Derivative, double );
    1037961extern Derivative derivative_of( double (*f)( double ) );
    … …  
    1045969For that interpretation, the function call is treated as ``\lstinline$?()( sin_dx, 12.9 )$''.
    1046970\begin{lstlisting}
    1047 int f( long );          // (1) 
    1048 int f( int, int );      // (2) 
     971int f( long );          // (1)
     972int f( int, int );      // (2)
    1049973int f( int *);          // (3)
    1050 
    1051974int i = f( 5 );         // calls (1)
    1052975\end{lstlisting}
    1053 Function (1) provides a valid interpretation of ``\lstinline$f( 5 )$'', using an implicit
    1054 \lstinline$int$ to \lstinline$long$ conversion. The other functions do not, since the second
    1055 requires two arguments, and since there is no implicit conversion from \lstinline$int$ to
    1056 \lstinline$int *$ that could be used with the third function.
    1057 
    1058 \begin{lstlisting}
    1059 forall( type T ) T h( T );
     976Function (1) provides a valid interpretation of ``\lstinline$f( 5 )$'', using an implicit \lstinline$int$ to \lstinline$long$ conversion.
     977The other functions do not, since the second requires two arguments, and since there is no implicit conversion from \lstinline$int$ to \lstinline$int *$ that could be used with the third function.
     978
     979\begin{lstlisting}
     980forall( otype T ) T h( T );
    1060981double d = h( 1.5 );
    1061982\end{lstlisting}
    … …  
    1064985
    1065986\begin{lstlisting}
    1066 forall( type T, type U ) void g( T, U );        // (4)
    1067 forall( type T ) void g( T, T );                        // (5)
    1068 forall( type T ) void g( T, long );                     // (6)
    1069 void g( long, long );                                           // (7) 
     987forall( otype T, otype U ) void g( T, U );      // (4)
     988forall( otype T ) void g( T, T );                       // (5)
     989forall( otype T ) void g( T, long );                    // (6)
     990void g( long, long );                                           // (7)
    1070991double d;
    1071992int i;
    1072993int *p;
    1073 
    1074 g( d, d );                      // calls (5)
    1075 g( d, i );                      // calls (6)
    1076 g( i, i );                      // calls (7)
     994g( d, d );                      // calls (5)
     995g( d, i );                      // calls (6)
     996g( i, i );                      // calls (7)
    1077997g( i, p );                      // calls (4)
    1078998\end{lstlisting}
    1079 The first call has valid interpretations for all four versions of \lstinline$g$. (6) and (7) are
    1080 discarded because they involve unsafe \lstinline$double$-to-\lstinline$long$ conversions. (5) is
    1081 chosen because it is less polymorphic than (4).
    1082 
    1083 For the second call, (7) is again discarded. Of the remaining interpretations for (4), (5), and (6)
    1084 (with \lstinline$i$ converted to \lstinline$long$), (6) is chosen because it is the least
    1085 polymorphic.
    1086 
    1087 The third call has valid interpretations for all of the functions; (7) is chosen since it is not
    1088 polymorphic at all.
    1089 
    1090 The fourth call has no interpretation for (5), because its arguments must have compatible type. (4)
    1091 is chosen because it does not involve unsafe conversions.
    1092 \begin{lstlisting}
    1093 forall( type T ) T min( T, T );
     999The first call has valid interpretations for all four versions of \lstinline$g$. (6) and (7) are discarded because they involve unsafe \lstinline$double$-to-\lstinline$long$ conversions. (5) is chosen because it is less polymorphic than (4).
     1000
     1001For the second call, (7) is again discarded.
     1002Of the remaining interpretations for (4), (5), and (6) (with \lstinline$i$ converted to \lstinline$long$), (6) is chosen because it is the least polymorphic.
     1003
     1004The third call has valid interpretations for all of the functions;
     1005(7) is chosen since it is not polymorphic at all.
     1006
     1007The fourth call has no interpretation for (5), because its arguments must have compatible type. (4) is chosen because it does not involve unsafe conversions.
     1008\begin{lstlisting}
     1009forall( otype T ) T min( T, T );
    10941010double max( double, double );
    1095 context min_max( T ) {@\impl{min_max}@
     1011trait min_max( T ) {@\impl{min_max}@
    10961012        T min( T, T );
    10971013        T max( T, T );
    10981014}
    1099 forall( type U | min_max( U ) ) void shuffle( U, U );
    1100 shuffle(9, 10);
    1101 \end{lstlisting}
    1102 The only possibility for \lstinline$U$ is \lstinline$double$, because that is the type used in the
    1103 only visible \lstinline$max$ function. 9 and 10 must be converted to \lstinline$double$, and
     1015forall( otype U | min_max( U ) ) void shuffle( U, U );
     1016shuffle( 9, 10 );
     1017\end{lstlisting}
     1018The only possibility for \lstinline$U$ is \lstinline$double$, because that is the type used in the only visible \lstinline$max$ function. 9 and 10 must be converted to \lstinline$double$, and
    11041019\lstinline$min$ must be specialized with \lstinline$T$ bound to \lstinline$double$.
    11051020\begin{lstlisting}
    1106 extern void q( int );           // (8) 
    1107 extern void q( void * );        // (9) 
     1021extern void q( int );           // (8)
     1022extern void q( void * );        // (9)
    11081023extern void r();
    11091024q( 0 );
    11101025r( 0 );
    11111026\end{lstlisting}
    1112 The \lstinline$int 0$ could be passed to (8), or the \lstinline$(void *)$ \Index{specialization} of
    1113 the null pointer\index{null pointer} \lstinline$0$\use{0} could be passed to (9). The former is
    1114 chosen because the \lstinline$int$ \lstinline$0$ is \Index{less polymorphic}. For
    1115 the same reason, \lstinline$int$ \lstinline$0$ is passed to \lstinline$r()$, even though it has
    1116 \emph{no} declared parameter types.
     1027The \lstinline$int 0$ could be passed to (8), or the \lstinline$(void *)$ \Index{specialization} of the null pointer\index{null pointer} \lstinline$0$\use{0} could be passed to (9).
     1028The former is chosen because the \lstinline$int$ \lstinline$0$ is \Index{less polymorphic}.
     1029For the same reason, \lstinline$int$ \lstinline$0$ is passed to \lstinline$r()$, even though it has \emph{no} declared parameter types.
    11171030
    11181031
    11191032\subsubsection{Structure and union members}
    11201033
    1121 \semantics In the member selection expression ``\lstinline$s$.\lstinline$m$'', there shall be at
    1122 least one interpretation of \lstinline$s$ whose type is a structure type or union type containing a
    1123 member named \lstinline$m$. If two or more interpretations of \lstinline$s$ have members named
    1124 \lstinline$m$ with mutually compatible types, then the expression has an \Index{ambiguous
    1125 interpretation} whose type is the composite type of the types of the members. If an interpretation
    1126 of \lstinline$s$ has a member \lstinline$m$ whose type is not compatible with any other
    1127 \lstinline$s$'s \lstinline$m$, then the expression has an interpretation with the member's type. The
    1128 expression has no other interpretations.
     1034\semantics In the member selection expression ``\lstinline$s$.\lstinline$m$'', there shall be at least one interpretation of \lstinline$s$ whose type is a structure type or union type containing a member named \lstinline$m$.
     1035If two or more interpretations of \lstinline$s$ have members named
     1036\lstinline$m$ with mutually compatible types, then the expression has an \Index{ambiguous interpretation} whose type is the composite type of the types of the members.
     1037If an interpretation of \lstinline$s$ has a member \lstinline$m$ whose type is not compatible with any other
     1038\lstinline$s$'s \lstinline$m$, then the expression has an interpretation with the member's type.
     1039The expression has no other interpretations.
    11291040
    11301041The expression ``\lstinline$p->m$'' has the same interpretations as the expression
    … …  
    11361047\predefined
    11371048\begin{lstlisting}
    1138 _Bool ?++( volatile _Bool * ),
    1139         ?++( _Atomic volatile _Bool * );
    1140 char ?++( volatile char * ),
    1141         ?++( _Atomic volatile char * );
    1142 signed char ?++( volatile signed char * ),
    1143         ?++( _Atomic volatile signed char * );
    1144 unsigned char ?++( volatile signed char * ),
    1145         ?++( _Atomic volatile signed char * );
    1146 short int ?++( volatile short int * ),
    1147         ?++( _Atomic volatile short int * );
    1148 unsigned short int ?++( volatile unsigned short int * ),
    1149         ?++( _Atomic volatile unsigned short int * );
    1150 int ?++( volatile int * ),
    1151         ?++( _Atomic volatile int * );
    1152 unsigned int ?++( volatile unsigned int * ),
    1153         ?++( _Atomic volatile unsigned int * );
    1154 long int ?++( volatile long int * ),
    1155         ?++( _Atomic volatile long int * );
    1156 long unsigned int ?++( volatile long unsigned int * ),
    1157         ?++( _Atomic volatile long unsigned int * );
    1158 long long int ?++( volatile long long int * ),
    1159         ?++( _Atomic volatile long long int * );
    1160 long long unsigned ?++( volatile long long unsigned int * ),
    1161         ?++( _Atomic volatile long long unsigned int * );
    1162 float ?++( volatile float * ),
    1163         ?++( _Atomic volatile float * );
    1164 double ?++( volatile double * ),
    1165         ?++( _Atomic volatile double * );
    1166 long double ?++( volatile long double * ),
    1167         ?++( _Atomic volatile long double * );
    1168 
    1169 forall( type T ) T * ?++( T * restrict volatile * ),
    1170         * ?++( T * _Atomic restrict volatile * );
    1171 
    1172 forall( type T ) _Atomic T * ?++( _Atomic T * restrict volatile * ),
    1173         * ?++( _Atomic T * _Atomic restrict volatile * );
    1174 
    1175 forall( type T ) const T * ?++( const T * restrict volatile * ),
    1176         * ?++( const T * _Atomic restrict volatile * );
    1177 
    1178 forall( type T ) volatile T * ?++( volatile T * restrict volatile * ),
    1179         * ?++( volatile T * _Atomic restrict volatile * );
    1180 
    1181 forall( type T ) restrict T * ?++( restrict T * restrict volatile * ),
    1182         * ?++( restrict T * _Atomic restrict volatile * );
    1183 
    1184 forall( type T ) _Atomic const T * ?++( _Atomic const T * restrict volatile * ),
     1049_Bool ?++( volatile _Bool * ), ?++( _Atomic volatile _Bool * );
     1050char ?++( volatile char * ), ?++( _Atomic volatile char * );
     1051signed char ?++( volatile signed char * ), ?++( _Atomic volatile signed char * );
     1052unsigned char ?++( volatile signed char * ), ?++( _Atomic volatile signed char * );
     1053short int ?++( volatile short int * ), ?++( _Atomic volatile short int * );
     1054unsigned short int ?++( volatile unsigned short int * ), ?++( _Atomic volatile unsigned short int * );
     1055int ?++( volatile int * ), ?++( _Atomic volatile int * );
     1056unsigned int ?++( volatile unsigned int * ), ?++( _Atomic volatile unsigned int * );
     1057long int ?++( volatile long int * ), ?++( _Atomic volatile long int * );
     1058long unsigned int ?++( volatile long unsigned int * ), ?++( _Atomic volatile long unsigned int * );
     1059long long int ?++( volatile long long int * ), ?++( _Atomic volatile long long int * );
     1060long long unsigned ?++( volatile long long unsigned int * ), ?++( _Atomic volatile long long unsigned int * );
     1061float ?++( volatile float * ), ?++( _Atomic volatile float * );
     1062double ?++( volatile double * ), ?++( _Atomic volatile double * );
     1063long double ?++( volatile long double * ), ?++( _Atomic volatile long double * );
     1064
     1065forall( otype T ) T * ?++( T * restrict volatile * ), * ?++( T * _Atomic restrict volatile * );
     1066forall( otype T ) _Atomic T * ?++( _Atomic T * restrict volatile * ), * ?++( _Atomic T * _Atomic restrict volatile * );
     1067forall( otype T ) const T * ?++( const T * restrict volatile * ), * ?++( const T * _Atomic restrict volatile * );
     1068forall( otype T ) volatile T * ?++( volatile T * restrict volatile * ), * ?++( volatile T * _Atomic restrict volatile * );
     1069forall( otype T ) restrict T * ?++( restrict T * restrict volatile * ), * ?++( restrict T * _Atomic restrict volatile * );
     1070forall( otype T ) _Atomic const T * ?++( _Atomic const T * restrict volatile * ),
    11851071        * ?++( _Atomic const T * _Atomic restrict volatile * );
    1186 
    1187 forall( type T ) _Atomic restrict T * ?++( _Atomic restrict T * restrict volatile * ),
     1072forall( otype T ) _Atomic restrict T * ?++( _Atomic restrict T * restrict volatile * ),
    11881073        * ?++( _Atomic restrict T * _Atomic restrict volatile * );
    1189 
    1190 forall( type T ) _Atomic volatile T * ?++( _Atomic volatile T * restrict volatile * ),
     1074forall( otype T ) _Atomic volatile T * ?++( _Atomic volatile T * restrict volatile * ),
    11911075        * ?++( _Atomic volatile T * _Atomic restrict volatile * );
    1192 
    1193 forall( type T ) const restrict T * ?++( const restrict T * restrict volatile * ),
     1076forall( otype T ) const restrict T * ?++( const restrict T * restrict volatile * ),
    11941077        * ?++( const restrict T * _Atomic restrict volatile * );
    1195 
    1196 forall( type T ) const volatile T * ?++( const volatile T * restrict volatile * ),
     1078forall( otype T ) const volatile T * ?++( const volatile T * restrict volatile * ),
    11971079        * ?++( const volatile T * _Atomic restrict volatile * );
    1198 
    1199 forall( type T ) restrict volatile T * ?++( restrict volatile T * restrict volatile * ),
     1080forall( otype T ) restrict volatile T * ?++( restrict volatile T * restrict volatile * ),
    12001081        * ?++( restrict volatile T * _Atomic restrict volatile * );
    1201 
    1202 forall( type T ) _Atomic const restrict T * ?++( _Atomic const restrict T * restrict volatile * ),
     1082forall( otype T ) _Atomic const restrict T * ?++( _Atomic const restrict T * restrict volatile * ),
    12031083        * ?++( _Atomic const restrict T * _Atomic restrict volatile * );
    1204 
    1205 forall( type T ) _Atomic const volatile T * ?++( _Atomic const volatile T * restrict volatile * ),
     1084forall( otype T ) _Atomic const volatile T * ?++( _Atomic const volatile T * restrict volatile * ),
    12061085        * ?++( _Atomic const volatile T * _Atomic restrict volatile * );
    1207 
    1208 forall( type T ) _Atomic restrict volatile T * ?++( _Atomic restrict volatile T * restrict volatile * ),
     1086forall( otype T ) _Atomic restrict volatile T * ?++( _Atomic restrict volatile T * restrict volatile * ),
    12091087        * ?++( _Atomic restrict volatile T * _Atomic restrict volatile * );
    1210 
    1211 forall( type T ) const restrict volatile T * ?++( const restrict volatile T * restrict volatile * ),
     1088forall( otype T ) const restrict volatile T * ?++( const restrict volatile T * restrict volatile * ),
    12121089        * ?++( const restrict volatile T * _Atomic restrict volatile * );
    1213 
    1214 forall( type T ) _Atomic const restrict volatile T * ?++( _Atomic const restrict volatile T * restrict volatile * ),
     1090forall( otype T ) _Atomic const restrict volatile T * ?++( _Atomic const restrict volatile T * restrict volatile * ),
    12151091        * ?++( _Atomic const restrict volatile T * _Atomic restrict volatile * );
    12161092
    1217 _Bool ?--( volatile _Bool * ),
    1218         ?--( _Atomic volatile _Bool * );
    1219 char ?--( volatile char * ),
    1220         ?--( _Atomic volatile char * );
    1221 signed char ?--( volatile signed char * ),
    1222         ?--( _Atomic volatile signed char * );
    1223 unsigned char ?--( volatile signed char * ),
    1224         ?--( _Atomic volatile signed char * );
    1225 short int ?--( volatile short int * ),
    1226         ?--( _Atomic volatile short int * );
    1227 unsigned short int ?--( volatile unsigned short int * ),
    1228         ?--( _Atomic volatile unsigned short int * );
    1229 int ?--( volatile int * ),
    1230         ?--( _Atomic volatile int * );
    1231 unsigned int ?--( volatile unsigned int * ),
    1232         ?--( _Atomic volatile unsigned int * );
    1233 long int ?--( volatile long int * ),
    1234         ?--( _Atomic volatile long int * );
    1235 long unsigned int ?--( volatile long unsigned int * ),
    1236         ?--( _Atomic volatile long unsigned int * );
    1237 long long int ?--( volatile long long int * ),
    1238         ?--( _Atomic volatile long long int * );
    1239 long long unsigned ?--( volatile long long unsigned int * ),
    1240         ?--( _Atomic volatile long long unsigned int * );
    1241 float ?--( volatile float * ),
    1242         ?--( _Atomic volatile float * );
    1243 double ?--( volatile double * ),
    1244         ?--( _Atomic volatile double * );
    1245 long double ?--( volatile long double * ),
    1246         ?--( _Atomic volatile long double * );
    1247 
    1248 forall( type T ) T * ?--( T * restrict volatile * ),
    1249         * ?--( T * _Atomic restrict volatile * );
    1250 
    1251 forall( type T ) _Atomic T * ?--( _Atomic T * restrict volatile * ),
    1252         * ?--( _Atomic T * _Atomic restrict volatile * );
    1253 
    1254 forall( type T ) const T * ?--( const T * restrict volatile * ),
    1255         * ?--( const T * _Atomic restrict volatile * );
    1256 
    1257 forall( type T ) volatile T * ?--( volatile T * restrict volatile * ),
    1258         * ?--( volatile T * _Atomic restrict volatile * );
    1259 
    1260 forall( type T ) restrict T * ?--( restrict T * restrict volatile * ),
    1261         * ?--( restrict T * _Atomic restrict volatile * );
    1262 
    1263 forall( type T ) _Atomic const T * ?--( _Atomic const T * restrict volatile * ),
     1093_Bool ?--( volatile _Bool * ), ?--( _Atomic volatile _Bool * );
     1094char ?--( volatile char * ), ?--( _Atomic volatile char * );
     1095signed char ?--( volatile signed char * ), ?--( _Atomic volatile signed char * );
     1096unsigned char ?--( volatile signed char * ), ?--( _Atomic volatile signed char * );
     1097short int ?--( volatile short int * ), ?--( _Atomic volatile short int * );
     1098unsigned short int ?--( volatile unsigned short int * ), ?--( _Atomic volatile unsigned short int * );
     1099int ?--( volatile int * ), ?--( _Atomic volatile int * );
     1100unsigned int ?--( volatile unsigned int * ), ?--( _Atomic volatile unsigned int * );
     1101long int ?--( volatile long int * ), ?--( _Atomic volatile long int * );
     1102long unsigned int ?--( volatile long unsigned int * ), ?--( _Atomic volatile long unsigned int * );
     1103long long int ?--( volatile long long int * ), ?--( _Atomic volatile long long int * );
     1104long long unsigned ?--( volatile long long unsigned int * ), ?--( _Atomic volatile long long unsigned int * );
     1105float ?--( volatile float * ), ?--( _Atomic volatile float * );
     1106double ?--( volatile double * ), ?--( _Atomic volatile double * );
     1107long double ?--( volatile long double * ), ?--( _Atomic volatile long double * );
     1108
     1109forall( otype T ) T * ?--( T * restrict volatile * ), * ?--( T * _Atomic restrict volatile * );
     1110forall( otype T ) _Atomic T * ?--( _Atomic T * restrict volatile * ), * ?--( _Atomic T * _Atomic restrict volatile * );
     1111forall( otype T ) const T * ?--( const T * restrict volatile * ), * ?--( const T * _Atomic restrict volatile * );
     1112forall( otype T ) volatile T * ?--( volatile T * restrict volatile * ), * ?--( volatile T * _Atomic restrict volatile * );
     1113forall( otype T ) restrict T * ?--( restrict T * restrict volatile * ), * ?--( restrict T * _Atomic restrict volatile * );
     1114forall( otype T ) _Atomic const T * ?--( _Atomic const T * restrict volatile * ),
    12641115        * ?--( _Atomic const T * _Atomic restrict volatile * );
    1265 
    1266 forall( type T ) _Atomic restrict T * ?--( _Atomic restrict T * restrict volatile * ),
     1116forall( otype T ) _Atomic restrict T * ?--( _Atomic restrict T * restrict volatile * ),
    12671117        * ?--( _Atomic restrict T * _Atomic restrict volatile * );
    1268 
    1269 forall( type T ) _Atomic volatile T * ?--( _Atomic volatile T * restrict volatile * ),
     1118forall( otype T ) _Atomic volatile T * ?--( _Atomic volatile T * restrict volatile * ),
    12701119        * ?--( _Atomic volatile T * _Atomic restrict volatile * );
    1271 
    1272 forall( type T ) const restrict T * ?--( const restrict T * restrict volatile * ),
     1120forall( otype T ) const restrict T * ?--( const restrict T * restrict volatile * ),
    12731121        * ?--( const restrict T * _Atomic restrict volatile * );
    1274 
    1275 forall( type T ) const volatile T * ?--( const volatile T * restrict volatile * ),
     1122forall( otype T ) const volatile T * ?--( const volatile T * restrict volatile * ),
    12761123        * ?--( const volatile T * _Atomic restrict volatile * );
    1277 
    1278 forall( type T ) restrict volatile T * ?--( restrict volatile T * restrict volatile * ),
     1124forall( otype T ) restrict volatile T * ?--( restrict volatile T * restrict volatile * ),
    12791125        * ?--( restrict volatile T * _Atomic restrict volatile * );
    1280 
    1281 forall( type T ) _Atomic const restrict T * ?--( _Atomic const restrict T * restrict volatile * ),
     1126forall( otype T ) _Atomic const restrict T * ?--( _Atomic const restrict T * restrict volatile * ),
    12821127        * ?--( _Atomic const restrict T * _Atomic restrict volatile * );
    1283 
    1284 forall( type T ) _Atomic const volatile T * ?--( _Atomic const volatile T * restrict volatile * ),
     1128forall( otype T ) _Atomic const volatile T * ?--( _Atomic const volatile T * restrict volatile * ),
    12851129        * ?--( _Atomic const volatile T * _Atomic restrict volatile * );
    1286 
    1287 forall( type T ) _Atomic restrict volatile T * ?--( _Atomic restrict volatile T * restrict volatile * ),
     1130forall( otype T ) _Atomic restrict volatile T * ?--( _Atomic restrict volatile T * restrict volatile * ),
    12881131        * ?--( _Atomic restrict volatile T * _Atomic restrict volatile * );
    1289 
    1290 forall( type T ) const restrict volatile T * ?--( const restrict volatile T * restrict volatile * ),
     1132forall( otype T ) const restrict volatile T * ?--( const restrict volatile T * restrict volatile * ),
    12911133        * ?--( const restrict volatile T * _Atomic restrict volatile * );
    1292 
    1293 forall( type T ) _Atomic const restrict volatile T * ?--( _Atomic const restrict volatile T * restrict volatile * ),
     1134forall( otype T ) _Atomic const restrict volatile T * ?--( _Atomic const restrict volatile T * restrict volatile * ),
    12941135        * ?--( _Atomic const restrict volatile T * _Atomic restrict volatile * );
    12951136\end{lstlisting}
    … …  
    13081149
    13091150\begin{rationale}
    1310 Note that ``\lstinline$++$'' and ``\lstinline$--$'' are rewritten as function calls that are given a
    1311 pointer to that operand. (This is true of all operators that modify an operand.) As Hamish Macdonald
    1312 has pointed out, this forces the modified operand of such expressions to be an lvalue. This
    1313 partially enforces the C semantic rule that such operands must be \emph{modifiable} lvalues.
    1314 \end{rationale}
    1315 
    1316 \begin{rationale}
    1317 In C, a semantic rule requires that pointer operands of increment and decrement be pointers to
    1318 object types. Hence, \lstinline$void *$ objects cannot be incremented. In \CFA, the restriction
    1319 follows from the use of a \lstinline$type$ parameter in the predefined function definitions, as
    1320 opposed to \lstinline$dtype$, since only object types can be inferred arguments corresponding to the
    1321 type parameter \lstinline$T$.
     1151Note that ``\lstinline$++$'' and ``\lstinline$--$'' are rewritten as function calls that are given a pointer to that operand. (This is true of all operators that modify an operand.) As Hamish Macdonald has pointed out, this forces the modified operand of such expressions to be an lvalue.
     1152This partially enforces the C semantic rule that such operands must be \emph{modifiable} lvalues.
     1153\end{rationale}
     1154
     1155\begin{rationale}
     1156In C, a semantic rule requires that pointer operands of increment and decrement be pointers to object types.
     1157Hence, \lstinline$void *$ objects cannot be incremented.
     1158In \CFA, the restriction follows from the use of a \lstinline$type$ parameter in the predefined function definitions, as opposed to \lstinline$dtype$, since only object types can be inferred arguments corresponding to the type parameter \lstinline$T$.
    13221159\end{rationale}
    13231160
    13241161\semantics
    1325 First, each interpretation of the operand of an increment or decrement expression is considered
    1326 separately. For each interpretation that is a bit-field or is declared with the
    1327 \lstinline$register$\index{register@{\lstinline$register$}} \index{Itorage-class specifier}, the
    1328 expression has one valid interpretation, with the type of the operand, and the expression is
    1329 ambiguous if the operand is.
    1330 
    1331 For the remaining interpretations, the expression is rewritten, and the interpretations of the
    1332 expression are the interpretations of the corresponding function call. Finally, all interpretations
    1333 of the expression produced for the different interpretations of the operand are combined to produce
    1334 the interpretations of the expression as a whole; where interpretations have compatible result
    1335 types, the best interpretations are selected in the manner described for function call expressions.
     1162First, each interpretation of the operand of an increment or decrement expression is considered separately.
     1163For each interpretation that is a bit-field or is declared with the
     1164\lstinline$register$\index{register@{\lstinline$register$}} \index{Itorage-class specifier}, the expression has one valid interpretation, with the type of the operand, and the expression is ambiguous if the operand is.
     1165
     1166For the remaining interpretations, the expression is rewritten, and the interpretations of the expression are the interpretations of the corresponding function call.
     1167Finally, all interpretations of the expression produced for the different interpretations of the operand are combined to produce the interpretations of the expression as a whole; where interpretations have compatible result types, the best interpretations are selected in the manner described for function call expressions.
    13361168
    13371169\examples
    … …  
    13461178\lstinline$vs++$ calls the \lstinline$?++$ function with the \lstinline$volatile short *$ parameter.
    13471179\lstinline$s++$ does the same, applying the safe conversion from \lstinline$short int *$ to
    1348 \lstinline$volatile short int *$. Note that there is no conversion that adds an \lstinline$_Atomic$
    1349 qualifier, so the \lstinline$_Atomic volatile short int$ overloading does not provide a valid
    1350 interpretation.
     1180\lstinline$volatile short int *$.
     1181Note that there is no conversion that adds an \lstinline$_Atomic$ qualifier, so the \lstinline$_Atomic volatile short int$ overloading does not provide a valid interpretation.
    13511182\end{sloppypar}
    13521183
    1353 There is no safe conversion from \lstinline$const short int *$ to \lstinline$volatile short int *$,
    1354 and no \lstinline$?++$ function that accepts a \lstinline$const *$ parameter, so \lstinline$cs++$
    1355 has no valid interpretations.
    1356 
    1357 The best valid interpretation of \lstinline$as++$ calls the \lstinline$short ?++$ function with the
    1358 \lstinline$_Atomic volatile short int *$ parameter, applying a safe conversion to add the
    1359 \lstinline$volatile$ qualifier.
    1360 
    1361 \begin{lstlisting}
    1362 char * const restrict volatile * restrict volatile pqpc; pqpc++
    1363 char * * restrict volatile ppc; ppc++;
    1364 \end{lstlisting}
    1365 Since \lstinline$&(pqpc)$ has type \lstinline$char * const restrict volatile * restrict volatile *$,
    1366 the best valid interpretation of \lstinline$pqpc++$ calls the polymorphic \lstinline$?++$ function
    1367 with the \lstinline$const restrict volatile T * restrict volatile *$ parameter, inferring
    1368 \lstinline$T$ to be \lstinline$char *$.
    1369 
    1370 \begin{sloppypar}
    1371 \lstinline$ppc++$ calls the same function, again inferring \lstinline$T$ to be \lstinline$char *$,
    1372 and using the safe conversions from \lstinline$T$ to \lstinline$T const restrict volatile$.
    1373 \end{sloppypar}
    1374 
    1375 \begin{rationale}
    1376 Increment and decrement expressions show up a deficiency of \CFA's type system. There is no such
    1377 thing as a pointer to a register object or bit-field\index{deficiencies!pointers to bit-fields}.
    1378 Therefore, there is no way to define a function that alters them, and hence no way to define
    1379 increment and decrement functions for them. As a result, the semantics of increment and decrement
    1380 expressions must treat them specially. This holds true for all of the operators that may modify
    1381 such objects.
    1382 \end{rationale}
    1383 
    1384 \begin{rationale}
    1385 The polymorphic overloadings for pointer increment and decrement can be understood by considering
    1386 increasingly complex types.
     1184There is no safe conversion from \lstinline$const short int *$ to \lstinline$volatile short int *$, and no \lstinline$?++$ function that accepts a \lstinline$const *$ parameter, so \lstinline$cs++$ has no valid interpretations.
     1185
     1186The best valid interpretation of \lstinline$as++$ calls the \lstinline$short ?++$ function with the \lstinline$_Atomic volatile short int *$ parameter, applying a safe conversion to add the \lstinline$volatile$ qualifier.
     1187\begin{lstlisting}
     1188char * const restrict volatile * restrict volatile pqpc;
     1189pqpc++
     1190char * * restrict volatile ppc;
     1191ppc++;
     1192\end{lstlisting}
     1193Since \lstinline$&(pqpc)$ has type \lstinline$char * const restrict volatile * restrict volatile *$, the best valid interpretation of \lstinline$pqpc++$ calls the polymorphic \lstinline$?++$ function with the \lstinline$const restrict volatile T * restrict volatile *$ parameter, inferring \lstinline$T$ to be \lstinline$char *$.
     1194
     1195\lstinline$ppc++$ calls the same function, again inferring \lstinline$T$ to be \lstinline$char *$, and using the safe conversions from \lstinline$T$ to \lstinline$T const$ \lstinline$restrict volatile$.
     1196
     1197\begin{rationale}
     1198Increment and decrement expressions show up a deficiency of \CFA's type system.
     1199There is no such thing as a pointer to a register object or bit-field\index{deficiencies!pointers to bit-fields}.
     1200Therefore, there is no way to define a function that alters them, and hence no way to define increment and decrement functions for them.
     1201As a result, the semantics of increment and decrement expressions must treat them specially.
     1202This holds true for all of the operators that may modify such objects.
     1203\end{rationale}
     1204
     1205\begin{rationale}
     1206The polymorphic overloadings for pointer increment and decrement can be understood by considering increasingly complex types.
    13871207\begin{enumerate}
    13881208\item
    1389 ``\lstinline$char * p; p++;$''. The argument to \lstinline$?++$ has type \lstinline$char * *$, and
    1390 the result has type \lstinline$char *$. The expression would be valid if \lstinline$?++$ were
    1391 declared by
    1392 \begin{lstlisting}
    1393 forall( type T ) T * ?++( T * * );
    1394 \end{lstlisting}
    1395 with \lstinline$T$ inferred to be \lstinline$char$.
    1396 
    1397 \item
    1398 ``\lstinline$char *restrict volatile qp; qp++$''. The result again has type \lstinline$char *$, but
    1399 the argument now has type \lstinline$char *restrict volatile *$, so it cannot be passed to the
    1400 hypothetical function declared in point 1. Hence the actual predefined function is
    1401 \begin{lstlisting}
    1402 forall( type T ) T * ?++( T * restrict volatile * );
    1403 \end{lstlisting}
    1404 which also accepts a \lstinline$char * *$ argument, because of the safe conversions that add
    1405 \lstinline$volatile$ and \lstinline$restrict$ qualifiers. (The parameter is not const-qualified, so
    1406 constant pointers cannot be incremented.)
    1407 
    1408 \item
    1409 ``\lstinline$char *_Atomic ap; ap++$''. The result again has type \lstinline$char *$, but no safe
    1410 conversion adds an \lstinline$_Atomic$ qualifier, so the function in point 2 is not applicable. A
    1411 separate overloading of \lstinline$?++$ is required.
    1412 
    1413 \item
    1414 ``\lstinline$char const volatile * pq; pq++$''. Here the result has type
     1209``\lstinline$char * p; p++;$''.
     1210The argument to \lstinline$?++$ has type \lstinline$char * *$, and the result has type \lstinline$char *$.
     1211The expression would be valid if \lstinline$?++$ were declared by
     1212\begin{lstlisting}
     1213forall( otype T ) T * ?++( T * * );
     1214\end{lstlisting} with \lstinline$T$ inferred to be \lstinline$char$.
     1215
     1216\item
     1217``\lstinline$char *restrict volatile qp; qp++$''.
     1218The result again has type \lstinline$char *$, but the argument now has type \lstinline$char *restrict volatile *$, so it cannot be passed to the hypothetical function declared in point 1.
     1219Hence the actual predefined function is
     1220\begin{lstlisting}
     1221forall( otype T ) T * ?++( T * restrict volatile * );
     1222\end{lstlisting} which also accepts a \lstinline$char * *$ argument, because of the safe conversions that add
     1223\lstinline$volatile$ and \lstinline$restrict$ qualifiers. (The parameter is not const-qualified, so constant pointers cannot be incremented.)
     1224
     1225\item
     1226``\lstinline$char *_Atomic ap; ap++$''.
     1227The result again has type \lstinline$char *$, but no safe conversion adds an \lstinline$_Atomic$ qualifier, so the function in point 2 is not applicable.
     1228A separate overloading of \lstinline$?++$ is required.
     1229
     1230\item
     1231``\lstinline$char const volatile * pq; pq++$''.
     1232Here the result has type
    14151233\lstinline$char const volatile *$, so a new overloading is needed:
    14161234\begin{lstlisting}
    1417 forall( type T ) T const volatile * ?++( T const volatile *restrict volatile * );
    1418 \end{lstlisting}
    1419 One overloading is needed for each combination of qualifiers in the pointed-at
    1420 type\index{deficiencies!pointers to qualified types}.
     1235forall( otype T ) T const volatile * ?++( T const volatile *restrict volatile * );
     1236\end{lstlisting}
     1237One overloading is needed for each combination of qualifiers in the pointed-at type\index{deficiencies!pointers to qualified types}.
    14211238 
    14221239\item
    1423 ``\lstinline$float *restrict * prp; prp++$''. The \lstinline$restrict$ qualifier is handled just
    1424 like \lstinline$const$ and \lstinline$volatile$ in the previous case:
    1425 \begin{lstlisting}
    1426 forall( type T ) T restrict * ?++( T restrict *restrict volatile * );
    1427 \end{lstlisting}
    1428 with \lstinline$T$ inferred to be \lstinline$float *$. This looks odd, because {\c11} contains a
    1429 constraint that requires restrict-qualified types to be pointer-to-object types, and \lstinline$T$
    1430 is not syntactically a pointer type. \CFA loosens the constraint.
     1240``\lstinline$float *restrict * prp; prp++$''.
     1241The \lstinline$restrict$ qualifier is handled just like \lstinline$const$ and \lstinline$volatile$ in the previous case:
     1242\begin{lstlisting}
     1243forall( otype T ) T restrict * ?++( T restrict *restrict volatile * );
     1244\end{lstlisting} with \lstinline$T$ inferred to be \lstinline$float *$.
     1245This looks odd, because {\c11} contains a constraint that requires restrict-qualified types to be pointer-to-object types, and \lstinline$T$ is not syntactically a pointer type. \CFA loosens the constraint.
    14311246\end{enumerate}
    14321247\end{rationale}
    … …  
    14361251
    14371252\semantics
    1438 A compound literal has one interpretation, with the type given by the \nonterm{type-name} of the
    1439 compound literal.
     1253A compound literal has one interpretation, with the type given by the \nonterm{type-name} of the compound literal.
    14401254
    14411255
    … …  
    14551269\rewriterules
    14561270\begin{lstlisting}
    1457 *a      @\rewrite@ *?(a) @\use{*?}@
    1458 +a      @\rewrite@ +?(a) @\use{+?}@
    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{--?}@
     1271*a      @\rewrite@ *?( a ) @\use{*?}@
     1272+a      @\rewrite@ +?( a ) @\use{+?}@
     1273-a      @\rewrite@ -?( a ) @\use{-?}@
     1274~a      @\rewrite@ ~?( a ) @\use{~?}@
     1275!a      @\rewrite@ !?( a ) @\use{"!?}@
     1276++a     @\rewrite@ ++?(&( a )) @\use{++?}@
     1277--a     @\rewrite@ --?(&( a )) @\use{--?}@
    14641278\end{lstlisting}
    14651279
    … …  
    14691283\predefined
    14701284\begin{lstlisting}
    1471 _Bool ++?( volatile _Bool * ),
    1472         ++?( _Atomic volatile _Bool * );
    1473 char ++?( volatile char * ),
    1474         ++?( _Atomic volatile char * );
    1475 signed char ++?( volatile signed char * ),
    1476         ++?( _Atomic volatile signed char * );
    1477 unsigned char ++?( volatile signed char * ),
    1478         ++?( _Atomic volatile signed char * );
    1479 short int ++?( volatile short int * ),
    1480         ++?( _Atomic volatile short int * );
    1481 unsigned short int ++?( volatile unsigned short int * ),
    1482         ++?( _Atomic volatile unsigned short int * );
    1483 int ++?( volatile int * ),
    1484         ++?( _Atomic volatile int * );
    1485 unsigned int ++?( volatile unsigned int * ),
    1486         ++?( _Atomic volatile unsigned int * );
    1487 long int ++?( volatile long int * ),
    1488         ++?( _Atomic volatile long int * );
    1489 long unsigned int ++?( volatile long unsigned int * ),
    1490         ++?( _Atomic volatile long unsigned int * );
    1491 long long int ++?( volatile long long int * ),
    1492         ++?( _Atomic volatile long long int * );
    1493 long long unsigned ++?( volatile long long unsigned int * ),
    1494         ++?( _Atomic volatile long long unsigned int * );
    1495 float ++?( volatile float * ),
    1496         ++?( _Atomic volatile float * );
    1497 double ++?( volatile double * ),
    1498         ++?( _Atomic volatile double * );
    1499 long double ++?( volatile long double * ),
    1500         ++?( _Atomic volatile long double * );
    1501 
    1502 forall( type T ) T * ++?( T * restrict volatile * ),
    1503         * ++?( T * _Atomic restrict volatile * );
    1504 
    1505 forall( type T ) _Atomic T * ++?( _Atomic T * restrict volatile * ),
    1506         * ++?( _Atomic T * _Atomic restrict volatile * );
    1507 
    1508 forall( type T ) const T * ++?( const T * restrict volatile * ),
    1509         * ++?( const T * _Atomic restrict volatile * );
    1510 
    1511 forall( type T ) volatile T * ++?( volatile T * restrict volatile * ),
    1512         * ++?( volatile T * _Atomic restrict volatile * );
    1513 
    1514 forall( type T ) restrict T * ++?( restrict T * restrict volatile * ),
    1515         * ++?( restrict T * _Atomic restrict volatile * );
    1516 
    1517 forall( type T ) _Atomic const T * ++?( _Atomic const T * restrict volatile * ),
     1285_Bool ++?( volatile _Bool * ), ++?( _Atomic volatile _Bool * );
     1286char ++?( volatile char * ), ++?( _Atomic volatile char * );
     1287signed char ++?( volatile signed char * ), ++?( _Atomic volatile signed char * );
     1288unsigned char ++?( volatile signed char * ), ++?( _Atomic volatile signed char * );
     1289short int ++?( volatile short int * ), ++?( _Atomic volatile short int * );
     1290unsigned short int ++?( volatile unsigned short int * ), ++?( _Atomic volatile unsigned short int * );
     1291int ++?( volatile int * ), ++?( _Atomic volatile int * );
     1292unsigned int ++?( volatile unsigned int * ), ++?( _Atomic volatile unsigned int * );
     1293long int ++?( volatile long int * ), ++?( _Atomic volatile long int * );
     1294long unsigned int ++?( volatile long unsigned int * ), ++?( _Atomic volatile long unsigned int * );
     1295long long int ++?( volatile long long int * ), ++?( _Atomic volatile long long int * );
     1296long long unsigned ++?( volatile long long unsigned int * ), ++?( _Atomic volatile long long unsigned int * );
     1297float ++?( volatile float * ), ++?( _Atomic volatile float * );
     1298double ++?( volatile double * ), ++?( _Atomic volatile double * );
     1299long double ++?( volatile long double * ), ++?( _Atomic volatile long double * );
     1300
     1301forall( otype T ) T * ++?( T * restrict volatile * ), * ++?( T * _Atomic restrict volatile * );
     1302forall( otype T ) _Atomic T * ++?( _Atomic T * restrict volatile * ), * ++?( _Atomic T * _Atomic restrict volatile * );
     1303forall( otype T ) const T * ++?( const T * restrict volatile * ), * ++?( const T * _Atomic restrict volatile * );
     1304forall( otype T ) volatile T * ++?( volatile T * restrict volatile * ), * ++?( volatile T * _Atomic restrict volatile * );
     1305forall( otype T ) restrict T * ++?( restrict T * restrict volatile * ), * ++?( restrict T * _Atomic restrict volatile * );
     1306forall( otype T ) _Atomic const T * ++?( _Atomic const T * restrict volatile * ),
    15181307        * ++?( _Atomic const T * _Atomic restrict volatile * );
    1519 
    1520 forall( type T ) _Atomic volatile T * ++?( _Atomic volatile T * restrict volatile * ),
     1308forall( otype T ) _Atomic volatile T * ++?( _Atomic volatile T * restrict volatile * ),
    15211309        * ++?( _Atomic volatile T * _Atomic restrict volatile * );
    1522 
    1523 forall( type T ) _Atomic restrict T * ++?( _Atomic restrict T * restrict volatile * ),
     1310forall( otype T ) _Atomic restrict T * ++?( _Atomic restrict T * restrict volatile * ),
    15241311        * ++?( _Atomic restrict T * _Atomic restrict volatile * );
    1525 
    1526 forall( type T ) const volatile T * ++?( const volatile T * restrict volatile * ),
     1312forall( otype T ) const volatile T * ++?( const volatile T * restrict volatile * ),
    15271313        * ++?( const volatile T * _Atomic restrict volatile * );
    1528 
    1529 forall( type T ) const restrict T * ++?( const restrict T * restrict volatile * ),
     1314forall( otype T ) const restrict T * ++?( const restrict T * restrict volatile * ),
    15301315        * ++?( const restrict T * _Atomic restrict volatile * );
    1531 
    1532 forall( type T ) restrict volatile T * ++?( restrict volatile T * restrict volatile * ),
     1316forall( otype T ) restrict volatile T * ++?( restrict volatile T * restrict volatile * ),
    15331317        * ++?( restrict volatile T * _Atomic restrict volatile * );
    1534 
    1535 forall( type T ) _Atomic const volatile T * ++?( _Atomic const volatile T * restrict volatile * ),
     1318forall( otype T ) _Atomic const volatile T * ++?( _Atomic const volatile T * restrict volatile * ),
    15361319        * ++?( _Atomic const volatile T * _Atomic restrict volatile * );
    1537 
    1538 forall( type T ) _Atomic const restrict T * ++?( _Atomic const restrict T * restrict volatile * ),
     1320forall( otype T ) _Atomic const restrict T * ++?( _Atomic const restrict T * restrict volatile * ),
    15391321        * ++?( _Atomic const restrict T * _Atomic restrict volatile * );
    1540 
    1541 forall( type T ) _Atomic restrict volatile T * ++?( _Atomic restrict volatile T * restrict volatile * ),
     1322forall( otype T ) _Atomic restrict volatile T * ++?( _Atomic restrict volatile T * restrict volatile * ),
    15421323        * ++?( _Atomic restrict volatile T * _Atomic restrict volatile * );
    1543 
    1544 forall( type T ) const restrict volatile T * ++?( const restrict volatile T * restrict volatile * ),
     1324forall( otype T ) const restrict volatile T * ++?( const restrict volatile T * restrict volatile * ),
    15451325        * ++?( const restrict volatile T * _Atomic restrict volatile * );
    1546 
    1547 forall( type T ) _Atomic const restrict volatile T * ++?( _Atomic const restrict volatile T * restrict volatile * ),
     1326forall( otype T ) _Atomic const restrict volatile T * ++?( _Atomic const restrict volatile T * restrict volatile * ),
    15481327        * ++?( _Atomic const restrict volatile T * _Atomic restrict volatile * );
    15491328
    1550 _Bool --?( volatile _Bool * ),
    1551         --?( _Atomic volatile _Bool * );
    1552 char --?( volatile char * ),
    1553         --?( _Atomic volatile char * );
    1554 signed char --?( volatile signed char * ),
    1555         --?( _Atomic volatile signed char * );
    1556 unsigned char --?( volatile signed char * ),
    1557         --?( _Atomic volatile signed char * );
    1558 short int --?( volatile short int * ),
    1559         --?( _Atomic volatile short int * );
    1560 unsigned short int --?( volatile unsigned short int * ),
    1561         --?( _Atomic volatile unsigned short int * );
    1562 int --?( volatile int * ),
    1563         --?( _Atomic volatile int * );
    1564 unsigned int --?( volatile unsigned int * ),
    1565         --?( _Atomic volatile unsigned int * );
    1566 long int --?( volatile long int * ),
    1567         --?( _Atomic volatile long int * );
    1568 long unsigned int --?( volatile long unsigned int * ),
    1569         --?( _Atomic volatile long unsigned int * );
    1570 long long int --?( volatile long long int * ),
    1571         --?( _Atomic volatile long long int * );
    1572 long long unsigned --?( volatile long long unsigned int * ),
    1573         --?( _Atomic volatile long long unsigned int * );
    1574 float --?( volatile float * ),
    1575         --?( _Atomic volatile float * );
    1576 double --?( volatile double * ),
    1577         --?( _Atomic volatile double * );
    1578 long double --?( volatile long double * ),
    1579         --?( _Atomic volatile long double * );
    1580 
    1581 forall( type T ) T * --?( T * restrict volatile * ),
    1582         * --?( T * _Atomic restrict volatile * );
    1583 
    1584 forall( type T ) _Atomic T * --?( _Atomic T * restrict volatile * ),
    1585         * --?( _Atomic T * _Atomic restrict volatile * );
    1586 
    1587 forall( type T ) const T * --?( const T * restrict volatile * ),
    1588         * --?( const T * _Atomic restrict volatile * );
    1589 
    1590 forall( type T ) volatile T * --?( volatile T * restrict volatile * ),
    1591         * --?( volatile T * _Atomic restrict volatile * );
    1592 
    1593 forall( type T ) restrict T * --?( restrict T * restrict volatile * ),
    1594         * --?( restrict T * _Atomic restrict volatile * );
    1595 
    1596 forall( type T ) _Atomic const T * --?( _Atomic const T * restrict volatile * ),
     1329_Bool --?( volatile _Bool * ), --?( _Atomic volatile _Bool * );
     1330char --?( volatile char * ), --?( _Atomic volatile char * );
     1331signed char --?( volatile signed char * ), --?( _Atomic volatile signed char * );
     1332unsigned char --?( volatile signed char * ), --?( _Atomic volatile signed char * );
     1333short int --?( volatile short int * ), --?( _Atomic volatile short int * );
     1334unsigned short int --?( volatile unsigned short int * ), --?( _Atomic volatile unsigned short int * );
     1335int --?( volatile int * ), --?( _Atomic volatile int * );
     1336unsigned int --?( volatile unsigned int * ), --?( _Atomic volatile unsigned int * );
     1337long int --?( volatile long int * ), --?( _Atomic volatile long int * );
     1338long unsigned int --?( volatile long unsigned int * ), --?( _Atomic volatile long unsigned int * );
     1339long long int --?( volatile long long int * ), --?( _Atomic volatile long long int * );
     1340long long unsigned --?( volatile long long unsigned int * ), --?( _Atomic volatile long long unsigned int * );
     1341float --?( volatile float * ), --?( _Atomic volatile float * );
     1342double --?( volatile double * ), --?( _Atomic volatile double * );
     1343long double --?( volatile long double * ), --?( _Atomic volatile long double * );
     1344
     1345forall( otype T ) T * --?( T * restrict volatile * ), * --?( T * _Atomic restrict volatile * );
     1346forall( otype T ) _Atomic T * --?( _Atomic T * restrict volatile * ), * --?( _Atomic T * _Atomic restrict volatile * );
     1347forall( otype T ) const T * --?( const T * restrict volatile * ), * --?( const T * _Atomic restrict volatile * );
     1348forall( otype T ) volatile T * --?( volatile T * restrict volatile * ), * --?( volatile T * _Atomic restrict volatile * );
     1349forall( otype T ) restrict T * --?( restrict T * restrict volatile * ), * --?( restrict T * _Atomic restrict volatile * );
     1350forall( otype T ) _Atomic const T * --?( _Atomic const T * restrict volatile * ),
    15971351        * --?( _Atomic const T * _Atomic restrict volatile * );
    1598 
    1599 forall( type T ) _Atomic volatile T * --?( _Atomic volatile T * restrict volatile * ),
     1352forall( otype T ) _Atomic volatile T * --?( _Atomic volatile T * restrict volatile * ),
    16001353        * --?( _Atomic volatile T * _Atomic restrict volatile * );
    1601 
    1602 forall( type T ) _Atomic restrict T * --?( _Atomic restrict T * restrict volatile * ),
     1354forall( otype T ) _Atomic restrict T * --?( _Atomic restrict T * restrict volatile * ),
    16031355        * --?( _Atomic restrict T * _Atomic restrict volatile * );
    1604 
    1605 forall( type T ) const volatile T * --?( const volatile T * restrict volatile * ),
     1356forall( otype T ) const volatile T * --?( const volatile T * restrict volatile * ),
    16061357        * --?( const volatile T * _Atomic restrict volatile * );
    1607 
    1608 forall( type T ) const restrict T * --?( const restrict T * restrict volatile * ),
     1358forall( otype T ) const restrict T * --?( const restrict T * restrict volatile * ),
    16091359        * --?( const restrict T * _Atomic restrict volatile * );
    1610 
    1611 forall( type T ) restrict volatile T * --?( restrict volatile T * restrict volatile * ),
     1360forall( otype T ) restrict volatile T * --?( restrict volatile T * restrict volatile * ),
    16121361        * --?( restrict volatile T * _Atomic restrict volatile * );
    1613 
    1614 forall( type T ) _Atomic const volatile T * --?( _Atomic const volatile T * restrict volatile * ),
     1362forall( otype T ) _Atomic const volatile T * --?( _Atomic const volatile T * restrict volatile * ),
    16151363        * --?( _Atomic const volatile T * _Atomic restrict volatile * );
    1616 
    1617 forall( type T ) _Atomic const restrict T * --?( _Atomic const restrict T * restrict volatile * ),
     1364forall( otype T ) _Atomic const restrict T * --?( _Atomic const restrict T * restrict volatile * ),
    16181365        * --?( _Atomic const restrict T * _Atomic restrict volatile * );
    1619 
    1620 forall( type T ) _Atomic restrict volatile T * --?( _Atomic restrict volatile T * restrict volatile * ),
     1366forall( otype T ) _Atomic restrict volatile T * --?( _Atomic restrict volatile T * restrict volatile * ),
    16211367        * --?( _Atomic restrict volatile T * _Atomic restrict volatile * );
    1622 
    1623 forall( type T ) const restrict volatile T * --?( const restrict volatile T * restrict volatile * ),
     1368forall( otype T ) const restrict volatile T * --?( const restrict volatile T * restrict volatile * ),
    16241369        * --?( const restrict volatile T * _Atomic restrict volatile * );
    1625 
    1626 forall( type T ) _Atomic const restrict volatile T * --?( _Atomic const restrict volatile T * restrict volatile * ),
     1370forall( otype T ) _Atomic const restrict volatile T * --?( _Atomic const restrict volatile T * restrict volatile * ),
    16271371        * --?( _Atomic const restrict volatile T * _Atomic restrict volatile * );
    16281372\end{lstlisting}
    … …  
    16451389
    16461390\semantics
    1647 The interpretations of prefix increment and decrement expressions are
    1648 determined in the same way as the interpretations of postfix increment and
    1649 decrement expressions.
     1391The interpretations of prefix increment and decrement expressions are determined in the same way as the interpretations of postfix increment and decrement expressions.
    16501392
    16511393
    … …  
    16541396\predefined
    16551397\begin{lstlisting}
    1656 forall( type T ) lvalue T *?( T * );
    1657 forall( type T ) _Atomic lvalue T *?( _Atomic T * );
    1658 forall( type T ) const lvalue T *?( const T * );
    1659 forall( type T ) volatile lvalue T *?( volatile T * );
    1660 forall( type T ) restrict lvalue T *?( restrict T * );
    1661 forall( type T ) _Atomic const lvalue T *?( _Atomic const T * );
    1662 forall( type T ) _Atomic volatile lvalue T *?( _Atomic volatile T * );
    1663 forall( type T ) _Atomic restrict lvalue T *?( _Atomic restrict T * );
    1664 forall( type T ) const volatile lvalue T *?( const volatile T * );
    1665 forall( type T ) const restrict lvalue T *?( const restrict T * );
    1666 forall( type T ) restrict volatile lvalue T *?( restrict volatile T * );
    1667 forall( type T ) _Atomic const volatile lvalue T *?( _Atomic const volatile T * );
    1668 forall( type T ) _Atomic const restrict lvalue T *?( _Atomic const restrict T * );
    1669 forall( type T ) _Atomic restrict volatile lvalue T *?( _Atomic restrict volatile T * );
    1670 forall( type T ) const restrict volatile lvalue T *?( const restrict volatile T * );
    1671 forall( type T ) _Atomic const restrict volatile lvalue T *?( _Atomic const restrict volatile T * );
    1672 
     1398forall( otype T ) lvalue T *?( T * );
     1399forall( otype T ) _Atomic lvalue T *?( _Atomic T * );
     1400forall( otype T ) const lvalue T *?( const T * );
     1401forall( otype T ) volatile lvalue T *?( volatile T * );
     1402forall( otype T ) restrict lvalue T *?( restrict T * );
     1403forall( otype T ) _Atomic const lvalue T *?( _Atomic const T * );
     1404forall( otype T ) _Atomic volatile lvalue T *?( _Atomic volatile T * );
     1405forall( otype T ) _Atomic restrict lvalue T *?( _Atomic restrict T * );
     1406forall( otype T ) const volatile lvalue T *?( const volatile T * );
     1407forall( otype T ) const restrict lvalue T *?( const restrict T * );
     1408forall( otype T ) restrict volatile lvalue T *?( restrict volatile T * );
     1409forall( otype T ) _Atomic const volatile lvalue T *?( _Atomic const volatile T * );
     1410forall( otype T ) _Atomic const restrict lvalue T *?( _Atomic const restrict T * );
     1411forall( otype T ) _Atomic restrict volatile lvalue T *?( _Atomic restrict volatile T * );
     1412forall( otype T ) const restrict volatile lvalue T *?( const restrict volatile T * );
     1413forall( otype T ) _Atomic const restrict volatile lvalue T *?( _Atomic const restrict volatile T * );
    16731414forall( ftype FT ) FT *?( FT * );
    16741415\end{lstlisting}
    … …  
    16821423\lstinline$T$ is the type of the operand.
    16831424
    1684 The interpretations of an indirection expression are the interpretations of the corresponding
    1685 function call.
     1425The interpretations of an indirection expression are the interpretations of the corresponding function call.
    16861426
    16871427
    … …  
    16901430\predefined
    16911431\begin{lstlisting}
    1692 int
    1693         +?( int ),
    1694         -?( int ),
    1695         ~?( int );
    1696 unsigned int
    1697         +?( unsigned int ),
    1698         -?( unsigned int ),
    1699          ~?( unsigned int );
    1700 long int
    1701         +?( long int ),
    1702         -?( long int ),
    1703         ~?( long int );
    1704 long unsigned int
    1705         +?( long unsigned int ),
    1706         -?( long unsigned int ),
    1707         ~?( long unsigned int );
    1708 long long int
    1709         +?( long long int ),
    1710         -?( long long int ),
    1711         ~?( long long int );
    1712 long long unsigned int
    1713         +?( long long unsigned int ),
    1714         -?( long long unsigned int ),
    1715         ~?( long long unsigned int );
    1716 float
    1717         +?( float ),
    1718         -?( float );
    1719 double
    1720         +?( double ),
    1721         -?( double );
    1722 long double
    1723         +?( long double ),
    1724         -?( long double );
    1725 _Complex float
    1726         +?( _Complex float ),
    1727         -?( _Complex float );
    1728 _Complex double
    1729         +?( _Complex double ),
    1730         -?( _Complex double );
    1731 _Complex long double
    1732         +?( _Complex long double ),
    1733         -?( _Complex long double );
    1734 
    1735 int !?( int ),
    1736         !?( unsigned int ),
    1737         !?( long ),
    1738         !?( long unsigned int ),
    1739         !?( long long int ),
    1740         !?( long long unsigned int ),
    1741         !?( float ),
    1742         !?( double ),
    1743         !?( long double ),
    1744         !?( _Complex float ),
    1745         !?( _Complex double ),
    1746         !?( _Complex long double );
    1747 
     1432int     +?( int ), -?( int ), ~?( int );
     1433unsigned int +?( unsigned int ), -?( unsigned int ), ~?( unsigned int );
     1434long int +?( long int ), -?( long int ), ~?( long int );
     1435long unsigned int +?( long unsigned int ), -?( long unsigned int ), ~?( long unsigned int );
     1436long long int +?( long long int ), -?( long long int ), ~?( long long int );
     1437long long unsigned int +?( long long unsigned int ), -?( long long unsigned int ), ~?( long long unsigned int );
     1438float +?( float ), -?( float );
     1439double +?( double ), -?( double );
     1440long double +?( long double ), -?( long double );
     1441_Complex float +?( _Complex float ), -?( _Complex float );
     1442_Complex double +?( _Complex double ), -?( _Complex double );
     1443_Complex long double +?( _Complex long double ), -?( _Complex long double );
     1444int !?( int ), !?( unsigned int ), !?( long ), !?( long unsigned int ),
     1445        !?( long long int ), !?( long long unsigned int ),
     1446        !?( float ), !?( double ), !?( long double ),
     1447        !?( _Complex float ), !?( _Complex double ), !?( _Complex long double );
    17481448forall( dtype DT ) int !?( const restrict volatile DT * );
    17491449forall( dtype DT ) int !?( _Atomic const restrict volatile DT * );
    17501450forall( ftype FT ) int !?( FT * );
    17511451\end{lstlisting}
    1752 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the
    1753 rank of \lstinline$int$ there exist
     1452For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the rank of \lstinline$int$ there exist
    17541453% Don't use predefined: keep this out of prelude.cf.
    17551454\begin{lstlisting}
    … …  
    17591458
    17601459\semantics
    1761 The interpretations of a unary arithmetic expression are the interpretations of the corresponding
    1762 function call.
     1460The interpretations of a unary arithmetic expression are the interpretations of the corresponding function call.
    17631461
    17641462\examples
    … …  
    17661464long int li;
    17671465void eat_double( double );@\use{eat_double}@
    1768 
    1769 eat_double(-li ); // @\rewrite@ eat_double( -?( li ) );
     1466eat_double(-li ); // @\rewrite@ eat_double( -?( li ) );
    17701467\end{lstlisting}
    17711468The valid interpretations of ``\lstinline$-li$'' (assuming no extended integer types exist) are
    17721469\begin{center}
    1773 \begin{tabular}{llc}
    1774 interpretation & result type & expression conversion cost \\
     1470\begin{tabular}{llc} interpretation & result type & expression conversion cost \\
    17751471\hline
    17761472\lstinline$-?( (int)li )$                                       & \lstinline$int$                                       & (unsafe) \\
    … …  
    17881484\end{tabular}
    17891485\end{center}
    1790 The valid interpretations of the \lstinline$eat_double$ call, with the cost of the argument
    1791 conversion and the cost of the entire expression, are
     1486The valid interpretations of the \lstinline$eat_double$ call, with the cost of the argument conversion and the cost of the entire expression, are
    17921487\begin{center}
    1793 \begin{tabular}{lcc}
    1794 interpretation & argument cost & expression cost \\
     1488\begin{tabular}{lcc} interpretation & argument cost & expression cost \\
    17951489\hline
    17961490\lstinline$eat_double( (double)-?( (int)li) )$                                  & 7                     & (unsafe) \\
    … …  
    18081502\end{tabular}
    18091503\end{center}
    1810 Each has result type \lstinline$void$, so the best must be selected. The interpretations involving
    1811 unsafe conversions are discarded. The remainder have equal expression conversion costs, so the
     1504Each has result type \lstinline$void$, so the best must be selected.
     1505The interpretations involving unsafe conversions are discarded.
     1506The remainder have equal expression conversion costs, so the
    18121507``highest argument conversion cost'' rule is invoked, and the chosen interpretation is
    18131508\lstinline$eat_double( (double)-?(li) )$.
    … …  
    18201515\lstinline$dtype$, or \lstinline$ftype$.
    18211516
    1822 When the \lstinline$sizeof$\use{sizeof} operator is applied to an expression, the expression shall
    1823 have exactly one \Index{interpretation}\index{ambiguous interpretation}, which shall
    1824 be unambiguous. \semantics A \lstinline$sizeof$ or \lstinline$_Alignof$ expression has one
    1825 interpretation, of type \lstinline$size_t$.
     1517When the \lstinline$sizeof$\use{sizeof} operator is applied to an expression, the expression shall have exactly one \Index{interpretation}\index{ambiguous interpretation}, which shall be unambiguous. \semantics A \lstinline$sizeof$ or \lstinline$_Alignof$ expression has one interpretation, of type \lstinline$size_t$.
    18261518
    18271519When \lstinline$sizeof$ is applied to an identifier declared by a \nonterm{type-declaration} or a
    1828 \nonterm{type-parameter}, it yields the size in bytes of the type that implements the operand. When
    1829 the operand is an opaque type or an inferred type parameter\index{inferred parameter}, the
    1830 expression is not a constant expression.
     1520\nonterm{type-parameter}, it yields the size in bytes of the type that implements the operand.
     1521When the operand is an opaque type or an inferred type parameter\index{inferred parameter}, the expression is not a constant expression.
    18311522
    18321523When \lstinline$_Alignof$ is applied to an identifier declared by a \nonterm{type-declaration} or a
    1833 \nonterm{type-parameter}, it yields the alignment requirement of the type that implements the
    1834 operand. When the operand is an opaque type or an inferred type parameter\index{inferred
    1835 parameter}, the expression is not a constant expression.
    1836 \begin{rationale}
    1837 \begin{lstlisting}
    1838 type Pair = struct { int first, second; };
     1524\nonterm{type-parameter}, it yields the alignment requirement of the type that implements the operand.
     1525When the operand is an opaque type or an inferred type parameter\index{inferred parameter}, the expression is not a constant expression.
     1526\begin{rationale}
     1527\begin{lstlisting}
     1528otype Pair = struct { int first, second; };
    18391529size_t p_size = sizeof(Pair);           // constant expression
    1840 
    1841 extern type Rational;@\use{Rational}@
     1530extern otype Rational;@\use{Rational}@
    18421531size_t c_size = sizeof(Rational);       // non-constant expression
    1843 
    18441532forall(type T) T f(T p1, T p2) {
    18451533        size_t t_size = sizeof(T);              // non-constant expression
    … …  
    18471535}
    18481536\end{lstlisting}
    1849 ``\lstinline$sizeof Rational$'', although not statically known, is fixed. Within \lstinline$f()$,
     1537``\lstinline$sizeof Rational$'', although not statically known, is fixed.
     1538Within \lstinline$f()$,
    18501539``\lstinline$sizeof(T)$'' is fixed for each call of \lstinline$f()$, but may vary from call to call.
    18511540\end{rationale}
    … …  
    18671556
    18681557In a \Index{cast expression} ``\lstinline$($\nonterm{type-name}\lstinline$)e$'', if
    1869 \nonterm{type-name} is the type of an interpretation of \lstinline$e$, then that interpretation is
    1870 the only interpretation of the cast expression; otherwise, \lstinline$e$ shall have some
    1871 interpretation that can be converted to \nonterm{type-name}, and the interpretation of the cast
    1872 expression is the cast of the interpretation that can be converted at the lowest cost. The cast
    1873 expression's interpretation is ambiguous\index{ambiguous interpretation} if more than one
    1874 interpretation can be converted at the lowest cost or if the selected interpretation is ambiguous.
    1875 
    1876 \begin{rationale}
    1877 Casts can be used to eliminate ambiguity in expressions by selecting interpretations of
    1878 subexpressions, and to specialize polymorphic functions and values.
     1558\nonterm{type-name} is the type of an interpretation of \lstinline$e$, then that interpretation is the only interpretation of the cast expression;
     1559otherwise, \lstinline$e$ shall have some interpretation that can be converted to \nonterm{type-name}, and the interpretation of the cast expression is the cast of the interpretation that can be converted at the lowest cost.
     1560The cast expression's interpretation is ambiguous\index{ambiguous interpretation} if more than one interpretation can be converted at the lowest cost or if the selected interpretation is ambiguous.
     1561
     1562\begin{rationale}
     1563Casts can be used to eliminate ambiguity in expressions by selecting interpretations of subexpressions, and to specialize polymorphic functions and values.
    18791564\end{rationale}
    18801565
    … …  
    18991584\predefined
    19001585\begin{lstlisting}
    1901 int?*?( int, int ),
    1902         ?/?( int, int ),
    1903         ?%?( int, int );
    1904 unsigned int?*?( unsigned int, unsigned int ),
    1905         ?/?( unsigned int, unsigned int ),
    1906         ?%?( unsigned int, unsigned int );
    1907 long int?*?( long int, long int ),
    1908         ?/?( long, long ),
    1909         ?%?( long, long );
     1586int?*?( int, int ), ?/?( int, int ), ?%?( int, int );
     1587unsigned int?*?( unsigned int, unsigned int ), ?/?( unsigned int, unsigned int ), ?%?( unsigned int, unsigned int );
     1588long int?*?( long int, long int ), ?/?( long, long ), ?%?( long, long );
    19101589long unsigned int?*?( long unsigned int, long unsigned int ),
    1911         ?/?( long unsigned int, long unsigned int ),
    1912         ?%?( long unsigned int, long unsigned int );
    1913 long long int?*?( long long int, long long int ),
    1914         ?/?( long long int, long long int ),
     1590        ?/?( long unsigned int, long unsigned int ), ?%?( long unsigned int, long unsigned int );
     1591long long int?*?( long long int, long long int ), ?/?( long long int, long long int ),
    19151592        ?%?( long long int, long long int );
    19161593long long unsigned int ?*?( long long unsigned int, long long unsigned int ),
    1917         ?/?( long long unsigned int, long long unsigned int ),
    1918         ?%?( long long unsigned int, long long unsigned int );
    1919 float?*?( float, float ),
    1920         ?/?( float, float );
    1921 double?*?( double, double ),
    1922         ?/?( double, double );
    1923 long double?*?( long double, long double ),
    1924         ?/?( long double, long double );
    1925 _Complex float?*?( float, _Complex float ),
    1926         ?/?( float, _Complex float ),
    1927         ?*?( _Complex float, float ),
    1928         ?/?( _Complex float, float ),
    1929         ?*?( _Complex float, _Complex float ),
    1930         ?/?( _Complex float, _Complex float );
    1931 _Complex double?*?( double, _Complex double ),
    1932         ?/?( double, _Complex double ),
    1933         ?*?( _Complex double, double ),
    1934         ?/?( _Complex double, double ),
    1935         ?*?( _Complex double, _Complex double ),
    1936         ?/?( _Complex double, _Complex double );
    1937 _Complex long double?*?( long double, _Complex long double ),
    1938         ?/?( long double, _Complex long double ),
    1939         ?*?( _Complex long double, long double ),
    1940         ?/?( _Complex long double, long double ),
    1941         ?*?( _Complex long double, _Complex long double ),
    1942         ?/?( _Complex long double, _Complex long double );
    1943 \end{lstlisting}
    1944 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the
    1945 rank of \lstinline$int$ there exist
     1594        ?/?( long long unsigned int, long long unsigned int ), ?%?( long long unsigned int, long long unsigned int );
     1595float?*?( float, float ), ?/?( float, float );
     1596double?*?( double, double ), ?/?( double, double );
     1597long double?*?( long double, long double ), ?/?( long double, long double );
     1598_Complex float?*?( float, _Complex float ), ?/?( float, _Complex float ),
     1599        ?*?( _Complex float, float ), ?/?( _Complex float, float ),
     1600        ?*?( _Complex float, _Complex float ), ?/?( _Complex float, _Complex float );
     1601_Complex double?*?( double, _Complex double ), ?/?( double, _Complex double ),
     1602        ?*?( _Complex double, double ), ?/?( _Complex double, double ),
     1603        ?*?( _Complex double, _Complex double ), ?/?( _Complex double, _Complex double );
     1604_Complex long double?*?( long double, _Complex long double ), ?/?( long double, _Complex long double ),
     1605        ?*?( _Complex long double, long double ), ?/?( _Complex long double, long double ),
     1606        ?*?( _Complex long double, _Complex long double ), ?/?( _Complex long double, _Complex long double );
     1607\end{lstlisting}
     1608For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the rank of \lstinline$int$ there exist
    19461609% Don't use predefined: keep this out of prelude.cf.
    19471610\begin{lstlisting}
    … …  
    19511614\begin{rationale}
    19521615{\c11} does not include conversions from the \Index{real type}s to \Index{complex type}s in the
    1953 \Index{usual arithmetic conversion}s.  Instead it specifies conversion of the result of binary
    1954 operations on arguments from mixed type domains. \CFA's predefined operators match that pattern.
     1616\Index{usual arithmetic conversion}s.  Instead it specifies conversion of the result of binary operations on arguments from mixed type domains. \CFA's predefined operators match that pattern.
    19551617\end{rationale}
    19561618
    19571619\semantics
    1958 The interpretations of multiplicative expressions are the interpretations of the corresponding
    1959 function call.
     1620The interpretations of multiplicative expressions are the interpretations of the corresponding function call.
    19601621
    19611622\examples
    … …  
    19661627eat_double( li % i );
    19671628\end{lstlisting}
    1968 ``\lstinline$li % i$'' is rewritten as ``\lstinline$?%?(li, i )$''. The valid interpretations
    1969 of \lstinline$?%?(li, i )$, the cost\index{conversion cost} of converting their arguments, and
    1970 the cost of converting the result to \lstinline$double$ (assuming no extended integer types are
    1971 present ) are
     1629``\lstinline$li % i$'' is rewritten as ``\lstinline$?%?(li, i )$''.
     1630The valid interpretations of \lstinline$?%?(li, i )$, the cost\index{conversion cost} of converting their arguments, and the cost of converting the result to \lstinline$double$ (assuming no extended integer types are present ) are
    19721631\begin{center}
    1973 \begin{tabular}{lcc}
    1974 interpretation & argument cost & result cost \\
     1632\begin{tabular}{lcc} interpretation & argument cost & result cost \\
    19751633\hline
    19761634\lstinline$ ?%?( (int)li, i )$                                                                          & (unsafe)      & 6     \\
    19771635\lstinline$ ?%?( (unsigned)li,(unsigned)i )$                                            & (unsafe)      & 5     \\
    1978 \lstinline$ ?%?(li,(long)i )$                                                                           & 1                     & 4     \\
     1636\lstinline$ ?%?( li, (long)i )$                                                                         & 1                     & 4     \\
    19791637\lstinline$ ?%?( (long unsigned)li,(long unsigned)i )$                          & 3                     & 3     \\
    19801638\lstinline$ ?%?( (long long)li,(long long)i )$                                          & 5                     & 2     \\
    … …  
    19831641\end{center}
    19841642The best interpretation of \lstinline$eat_double( li, i )$ is
    1985 \lstinline$eat_double( (double)?%?(li, (long)i ))$, which has no unsafe conversions and the
    1986 lowest total cost.
    1987 
    1988 \begin{rationale}
    1989 {\c11} defines most arithmetic operations to apply an \Index{integer promotion} to any argument that
    1990 belongs to a type that has an \Index{integer conversion rank} less than that of \lstinline$int$.If
     1643\lstinline$eat_double( (double)?%?(li, (long)i ))$, which has no unsafe conversions and the lowest total cost.
     1644
     1645\begin{rationale}
     1646{\c11} defines most arithmetic operations to apply an \Index{integer promotion} to any argument that belongs to a type that has an \Index{integer conversion rank} less than that of \lstinline$int$.If
    19911647\lstinline$s$ is a \lstinline$short int$, ``\lstinline$s *s$'' does not have type \lstinline$short int$;
    1992 it is treated as ``\lstinline$( (int)s ) * ( (int)s )$'', and has type \lstinline$int$. \CFA matches
    1993 that pattern; it does not predefine ``\lstinline$short ?*?( short, short )$''.
    1994 
    1995 These ``missing'' operators limit polymorphism. Consider
    1996 \begin{lstlisting}
    1997 forall( type T | T ?*?( T, T ) ) T square( T );
     1648it is treated as ``\lstinline$( (int)s ) * ( (int)s )$'', and has type \lstinline$int$. \CFA matches that pattern;
     1649it does not predefine ``\lstinline$short ?*?( short, short )$''.
     1650
     1651These ``missing'' operators limit polymorphism.
     1652Consider
     1653\begin{lstlisting}
     1654forall( otype T | T ?*?( T, T ) ) T square( T );
    19981655short s;
    19991656square( s );
    … …  
    20011658Since \CFA does not define a multiplication operator for \lstinline$short int$,
    20021659\lstinline$square( s )$ is treated as \lstinline$square( (int)s )$, and the result has type
    2003 \lstinline$int$. This is mildly surprising, but it follows the {\c11} operator pattern.
     1660\lstinline$int$.
     1661This is mildly surprising, but it follows the {\c11} operator pattern.
    20041662
    20051663A more troubling example is
    20061664\begin{lstlisting}
    2007 forall( type T | ?*?( T, T ) ) T product( T[], int n );
     1665forall( otype T | ?*?( T, T ) ) T product( T[], int n );
    20081666short sa[5];
    20091667product( sa, 5);
    20101668\end{lstlisting}
    20111669This has no valid interpretations, because \CFA has no conversion from ``array of
    2012 \lstinline$short int$'' to ``array of \lstinline$int$''. The alternatives in such situations
    2013 include
     1670\lstinline$short int$'' to ``array of \lstinline$int$''.
     1671The alternatives in such situations include
    20141672\begin{itemize}
    20151673\item
    … …  
    20201678\lstinline$product$.
    20211679\item
    2022 Defining \lstinline$product$ to take as an argument a conversion function from the ``small'' type to
    2023 the operator's argument type.
     1680Defining \lstinline$product$ to take as an argument a conversion function from the ``small'' type to the operator's argument type.
    20241681\end{itemize}
    20251682\end{rationale}
    … …  
    20431700\predefined
    20441701\begin{lstlisting}
    2045 int?+?( int, int ),
    2046         ?-?( int, int );
    2047 unsigned int?+?( unsigned int, unsigned int ),
    2048         ?-?( unsigned int, unsigned int );
    2049 long int?+?( long int, long int ),
    2050         ?-?( long int, long int );
    2051 long unsigned int?+?( long unsigned int, long unsigned int ),
    2052         ?-?( long unsigned int, long unsigned int );
    2053 long long int?+?( long long int, long long int ),
    2054         ?-?( long long int, long long int );
     1702int?+?( int, int ), ?-?( int, int );
     1703unsigned int?+?( unsigned int, unsigned int ), ?-?( unsigned int, unsigned int );
     1704long int?+?( long int, long int ), ?-?( long int, long int );
     1705long unsigned int?+?( long unsigned int, long unsigned int ), ?-?( long unsigned int, long unsigned int );
     1706long long int?+?( long long int, long long int ), ?-?( long long int, long long int );
    20551707long long unsigned int ?+?( long long unsigned int, long long unsigned int ),
    20561708        ?-?( long long unsigned int, long long unsigned int );
    2057 float?+?( float, float ),
    2058         ?-?( float, float );
    2059 double?+?( double, double ),
    2060         ?-?( double, double );
    2061 long double?+?( long double, long double ),
    2062         ?-?( long double, long double );
    2063 _Complex float?+?( _Complex float, float ),
    2064         ?-?( _Complex float, float ),
    2065         ?+?( float, _Complex float ),
    2066         ?-?( float, _Complex float ),
    2067         ?+?( _Complex float, _Complex float ),
    2068         ?-?( _Complex float, _Complex float );
    2069 _Complex double?+?( _Complex double, double ),
    2070         ?-?( _Complex double, double ),
    2071         ?+?( double, _Complex double ),
    2072         ?-?( double, _Complex double ),
    2073         ?+?( _Complex double, _Complex double ),
    2074         ?-?( _Complex double, _Complex double );
    2075 _Complex long double?+?( _Complex long double, long double ),
    2076         ?-?( _Complex long double, long double ),
    2077         ?+?( long double, _Complex long double ),
    2078         ?-?( long double, _Complex long double ),
    2079         ?+?( _Complex long double, _Complex long double ),
    2080         ?-?( _Complex long double, _Complex long double );
    2081 
    2082 forall( type T ) T
    2083         * ?+?( T *, ptrdiff_t ),
    2084         * ?+?( ptrdiff_t, T * ),
    2085         * ?-?( T *, ptrdiff_t );
    2086 
    2087 forall( type T ) _Atomic T
    2088         * ?+?( _Atomic T *, ptrdiff_t ),
    2089         * ?+?( ptrdiff_t, _Atomic T * ),
     1709float?+?( float, float ), ?-?( float, float );
     1710double?+?( double, double ), ?-?( double, double );
     1711long double?+?( long double, long double ), ?-?( long double, long double );
     1712_Complex float?+?( _Complex float, float ), ?-?( _Complex float, float ),
     1713        ?+?( float, _Complex float ), ?-?( float, _Complex float ),
     1714        ?+?( _Complex float, _Complex float ), ?-?( _Complex float, _Complex float );
     1715_Complex double?+?( _Complex double, double ), ?-?( _Complex double, double ),
     1716        ?+?( double, _Complex double ), ?-?( double, _Complex double ),
     1717        ?+?( _Complex double, _Complex double ), ?-?( _Complex double, _Complex double );
     1718_Complex long double?+?( _Complex long double, long double ), ?-?( _Complex long double, long double ),
     1719        ?+?( long double, _Complex long double ), ?-?( long double, _Complex long double ),
     1720        ?+?( _Complex long double, _Complex long double ), ?-?( _Complex long double, _Complex long double );
     1721
     1722forall( otype T ) T * ?+?( T *, ptrdiff_t ), * ?+?( ptrdiff_t, T * ), * ?-?( T *, ptrdiff_t );
     1723forall( otype T ) _Atomic T * ?+?( _Atomic T *, ptrdiff_t ), * ?+?( ptrdiff_t, _Atomic T * ),
    20901724        * ?-?( _Atomic T *, ptrdiff_t );
    2091 
    2092 forall( type T ) const T
    2093         * ?+?( const T *, ptrdiff_t ),
    2094         * ?+?( ptrdiff_t, const T * ),
     1725forall( otype T ) const T * ?+?( const T *, ptrdiff_t ), * ?+?( ptrdiff_t, const T * ),
    20951726        * ?-?( const T *, ptrdiff_t );
    2096 
    2097 forall( type T ) restrict T
    2098         * ?+?( restrict T *, ptrdiff_t ),
    2099         * ?+?( ptrdiff_t, restrict T * ),
     1727forall( otype T ) restrict T * ?+?( restrict T *, ptrdiff_t ), * ?+?( ptrdiff_t, restrict T * ),
    21001728        * ?-?( restrict T *, ptrdiff_t );
    2101 
    2102 forall( type T ) volatile T
    2103         * ?+?( volatile T *, ptrdiff_t ),
    2104         * ?+?( ptrdiff_t, volatile T * ),
     1729forall( otype T ) volatile T * ?+?( volatile T *, ptrdiff_t ), * ?+?( ptrdiff_t, volatile T * ),
    21051730        * ?-?( volatile T *, ptrdiff_t );
    2106 
    2107 forall( type T ) _Atomic const T
    2108         * ?+?( _Atomic const T *, ptrdiff_t ),
    2109         * ?+?( ptrdiff_t, _Atomic const T * ),
     1731forall( otype T ) _Atomic const T * ?+?( _Atomic const T *, ptrdiff_t ), * ?+?( ptrdiff_t, _Atomic const T * ),
    21101732        * ?-?( _Atomic const T *, ptrdiff_t );
    2111 
    2112 forall( type T ) _Atomic restrict T
    2113         * ?+?( _Atomic restrict T *, ptrdiff_t ),
    2114         * ?+?( ptrdiff_t, _Atomic restrict T * ),
     1733forall( otype T ) _Atomic restrict T * ?+?( _Atomic restrict T *, ptrdiff_t ), * ?+?( ptrdiff_t, _Atomic restrict T * ),
    21151734        * ?-?( _Atomic restrict T *, ptrdiff_t );
    2116 
    2117 forall( type T ) _Atomic volatile T
    2118         * ?+?( _Atomic volatile T *, ptrdiff_t ),
    2119         * ?+?( ptrdiff_t, _Atomic volatile T * ),
     1735forall( otype T ) _Atomic volatile T * ?+?( _Atomic volatile T *, ptrdiff_t ), * ?+?( ptrdiff_t, _Atomic volatile T * ),
    21201736        * ?-?( _Atomic volatile T *, ptrdiff_t );
    2121 
    2122 forall( type T ) const restrict T
    2123         * ?+?( const restrict T *, ptrdiff_t ),
    2124         * ?+?( ptrdiff_t, const restrict T * ),
     1737forall( otype T ) const restrict T * ?+?( const restrict T *, ptrdiff_t ), * ?+?( ptrdiff_t, const restrict T * ),
    21251738        * ?-?( const restrict T *, ptrdiff_t );
    2126 
    2127 forall( type T ) const volatile T
    2128         * ?+?( const volatile T *, ptrdiff_t ),
    2129         * ?+?( ptrdiff_t, const volatile T * ),
     1739forall( otype T ) const volatile T * ?+?( const volatile T *, ptrdiff_t ), * ?+?( ptrdiff_t, const volatile T * ),
    21301740        * ?-?( const volatile T *, ptrdiff_t );
    2131 
    2132 forall( type T ) restrict volatile T
    2133         * ?+?( restrict volatile T *, ptrdiff_t ),
    2134         * ?+?( ptrdiff_t, restrict volatile T * ),
     1741forall( otype T ) restrict volatile T * ?+?( restrict volatile T *, ptrdiff_t ), * ?+?( ptrdiff_t, restrict volatile T * ),
    21351742        * ?-?( restrict volatile T *, ptrdiff_t );
    2136 
    2137 forall( type T ) _Atomic const restrict T
    2138         * ?+?( _Atomic const restrict T *, ptrdiff_t ),
     1743forall( otype T ) _Atomic const restrict T * ?+?( _Atomic const restrict T *, ptrdiff_t ),
    21391744        * ?+?( ptrdiff_t, _Atomic const restrict T * ),
    21401745        * ?-?( _Atomic const restrict T *, ptrdiff_t );
    2141 
    2142 forall( type T ) ptrdiff_t
     1746forall( otype T ) ptrdiff_t
    21431747        * ?-?( const restrict volatile T *, const restrict volatile T * ),
    21441748        * ?-?( _Atomic const restrict volatile T *, _Atomic const restrict volatile T * );
    21451749\end{lstlisting}
    2146 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the
    2147 rank of \lstinline$int$ there exist
     1750For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the rank of \lstinline$int$ there exist
    21481751% Don't use predefined: keep this out of prelude.cf.
    21491752\begin{lstlisting}
    … …  
    21521755
    21531756\semantics
    2154 The interpretations of additive expressions are the interpretations of the corresponding function
    2155 calls.
    2156 
    2157 \begin{rationale}
    2158 \lstinline$ptrdiff_t$ is an implementation-defined identifier defined in \lstinline$<stddef.h>$ that
    2159 is synonymous with a signed integral type that is large enough to hold the difference between two
    2160 pointers. It seems reasonable to use it for pointer addition as well. (This is technically a
    2161 difference between \CFA and C, which only specifies that pointer addition uses an \emph{integral}
    2162 argument.) Hence it is also used for subscripting, which is defined in terms of pointer addition.
    2163 The {\c11} standard uses \lstinline$size_t$ in several cases where a library function takes an
    2164 argument that is used as a subscript, but \lstinline$size_t$ is unsuitable here because it is an
    2165 unsigned type.
     1757The interpretations of additive expressions are the interpretations of the corresponding function calls.
     1758
     1759\begin{rationale}
     1760\lstinline$ptrdiff_t$ is an implementation-defined identifier defined in \lstinline$<stddef.h>$ that is synonymous with a signed integral type that is large enough to hold the difference between two pointers.
     1761It seems reasonable to use it for pointer addition as well. (This is technically a difference between \CFA and C, which only specifies that pointer addition uses an \emph{integral} argument.) Hence it is also used for subscripting, which is defined in terms of pointer addition.
     1762The {\c11} standard uses \lstinline$size_t$ in several cases where a library function takes an argument that is used as a subscript, but \lstinline$size_t$ is unsuitable here because it is an unsigned type.
    21661763\end{rationale}
    21671764
    … …  
    21841781\predefined
    21851782\begin{lstlisting}
    2186 int ?<<?( int, int ),
    2187          ?>>?( int, int );
    2188 unsigned int ?<<?( unsigned int, int ),
    2189          ?>>?( unsigned int, int );
    2190 long int ?<<?( long int, int ),
    2191          ?>>?( long int, int );
    2192 long unsigned int ?<<?( long unsigned int, int ),
    2193          ?>>?( long unsigned int, int );
    2194 long long int ?<<?( long long int, int ),
    2195          ?>>?( long long int, int );
    2196 long long unsigned int ?<<?( long long unsigned int, int ),
    2197          ?>>?( long long unsigned int, int);
    2198 \end{lstlisting}
    2199 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the
    2200 rank of \lstinline$int$ there exist
     1783int ?<<?( int, int ), ?>>?( int, int );
     1784unsigned int ?<<?( unsigned int, int ), ?>>?( unsigned int, int );
     1785long int ?<<?( long int, int ), ?>>?( long int, int );
     1786long unsigned int ?<<?( long unsigned int, int ), ?>>?( long unsigned int, int );
     1787long long int ?<<?( long long int, int ), ?>>?( long long int, int );
     1788long long unsigned int ?<<?( long long unsigned int, int ), ?>>?( long long unsigned int, int);
     1789\end{lstlisting}
     1790For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the rank of \lstinline$int$ there exist
    22011791% Don't use predefined: keep this out of prelude.cf.
    22021792\begin{lstlisting}
    … …  
    22051795
    22061796\begin{rationale}
    2207 The bitwise shift operators break the usual pattern: they do not convert both operands to a common
    2208 type. The right operand only undergoes \Index{integer promotion}.
     1797The bitwise shift operators break the usual pattern: they do not convert both operands to a common type.
     1798The right operand only undergoes \Index{integer promotion}.
    22091799\end{rationale}
    22101800
    22111801\semantics
    2212 The interpretations of a bitwise shift expression are the interpretations of the corresponding
    2213 function calls.
     1802The interpretations of a bitwise shift expression are the interpretations of the corresponding function calls.
    22141803
    22151804
    … …  
    22351824\predefined
    22361825\begin{lstlisting}
    2237 int ?<?( int, int ),
    2238         ?<=?( int, int ),
    2239         ?>?( int, int ),
    2240         ?>=?( int, int );
    2241 int ?<?( unsigned int, unsigned int ),
    2242         ?<=?( unsigned int, unsigned int ),
    2243         ?>?( unsigned int, unsigned int ),
    2244         ?>=?( unsigned int, unsigned int );
    2245 int ?<?( long int, long int ),
    2246         ?<=?( long int, long int ),
    2247         ?>?( long int, long int ),
    2248         ?>=?( long int, long int );
    2249 int ?<?( long unsigned int, long unsigned ),
    2250         ?<=?( long unsigned int, long unsigned ),
    2251         ?>?( long unsigned int, long unsigned ),
    2252         ?>=?( long unsigned int, long unsigned );
    2253 int ?<?( long long int, long long int ),
    2254         ?<=?( long long int, long long int ),
    2255         ?>?( long long int, long long int ),
    2256         ?>=?( long long int, long long int );
    2257 int ?<?( long long unsigned int, long long unsigned ),
    2258         ?<=?( long long unsigned int, long long unsigned ),
    2259         ?>?( long long unsigned int, long long unsigned ),
    2260         ?>=?( long long unsigned int, long long unsigned );
    2261 int ?<?( float, float ),
    2262         ?<=?( float, float ),
    2263         ?>?( float, float ),
    2264         ?>=?( float, float );
    2265 int ?<?( double, double ),
    2266         ?<=?( double, double ),
    2267         ?>?( double, double ),
    2268         ?>=?( double, double );
    2269 int ?<?( long double, long double ),
    2270         ?<=?( long double, long double ),
    2271         ?>?( long double, long double ),
    2272         ?>=?( long double, long double );
    2273 
    2274 forall( dtype DT ) int
    2275         ?<?( const restrict volatile DT *, const restrict volatile DT * ),
     1826int ?<?( int, int ), ?<=?( int, int ),
     1827        ?>?( int, int ), ?>=?( int, int );
     1828int ?<?( unsigned int, unsigned int ), ?<=?( unsigned int, unsigned int ),
     1829        ?>?( unsigned int, unsigned int ), ?>=?( unsigned int, unsigned int );
     1830int ?<?( long int, long int ), ?<=?( long int, long int ),
     1831        ?>?( long int, long int ), ?>=?( long int, long int );
     1832int ?<?( long unsigned int, long unsigned ), ?<=?( long unsigned int, long unsigned ),
     1833        ?>?( long unsigned int, long unsigned ), ?>=?( long unsigned int, long unsigned );
     1834int ?<?( long long int, long long int ), ?<=?( long long int, long long int ),
     1835        ?>?( long long int, long long int ), ?>=?( long long int, long long int );
     1836int ?<?( long long unsigned int, long long unsigned ), ?<=?( long long unsigned int, long long unsigned ),
     1837        ?>?( long long unsigned int, long long unsigned ), ?>=?( long long unsigned int, long long unsigned );
     1838int ?<?( float, float ), ?<=?( float, float ),
     1839        ?>?( float, float ), ?>=?( float, float );
     1840int ?<?( double, double ), ?<=?( double, double ),
     1841        ?>?( double, double ), ?>=?( double, double );
     1842int ?<?( long double, long double ), ?<=?( long double, long double ),
     1843        ?>?( long double, long double ), ?>=?( long double, long double );
     1844forall( dtype DT ) int ?<?( const restrict volatile DT *, const restrict volatile DT * ),
    22761845        ?<?( _Atomic const restrict volatile DT *, _Atomic const restrict volatile DT * ),
    22771846        ?<=?( const restrict volatile DT *, const restrict volatile DT * ),
    … …  
    22821851        ?>=?( _Atomic const restrict volatile DT *, _Atomic const restrict volatile DT * );
    22831852\end{lstlisting}
    2284 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the
    2285 rank of \lstinline$int$ there exist
     1853For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the rank of \lstinline$int$ there exist
    22861854% Don't use predefined: keep this out of prelude.cf.
    22871855\begin{lstlisting}
    … …  
    22931861
    22941862\semantics
    2295 The interpretations of a relational expression are the interpretations of the corresponding function
    2296 call.
     1863The interpretations of a relational expression are the interpretations of the corresponding function call.
    22971864
    22981865
    … …  
    23141881\predefined
    23151882\begin{lstlisting}
    2316 int ?==?( int, int ),
    2317         ?!=?( int, int ),
    2318         ?==?( unsigned int, unsigned int ),
    2319         ?!=?( unsigned int, unsigned int ),
    2320         ?==?( long int, long int ),
    2321         ?!=?( long int, long int ),
    2322         ?==?( long unsigned int, long unsigned int ),
    2323         ?!=?( long unsigned int, long unsigned int ),
    2324         ?==?( long long int, long long int ),
    2325         ?!=?( long long int, long long int ),
    2326         ?==?( long long unsigned int, long long unsigned int ),
    2327         ?!=?( long long unsigned int, long long unsigned int ),
    2328         ?==?( float, float ),
    2329         ?!=?( float, float ),
    2330         ?==?( _Complex float, float ),
    2331         ?!=?( _Complex float, float ),
    2332         ?==?( float, _Complex float ),
    2333         ?!=?( float, _Complex float ),
    2334         ?==?( _Complex float, _Complex float ),
    2335         ?!=?( _Complex float, _Complex float ),
    2336         ?==?( double, double ),
    2337         ?!=?( double, double ),
    2338         ?==?( _Complex double, double ),
    2339         ?!=?( _Complex double, double ),
    2340         ?==?( double, _Complex double ),
    2341         ?!=?( double, _Complex double ),
    2342         ?==?( _Complex double, _Complex double ),
    2343         ?!=?( _Complex double, _Complex double ),
    2344         ?==?( long double, long double ),
    2345         ?!=?( long double, long double ),
    2346         ?==?( _Complex long double, long double ),
    2347         ?!=?( _Complex long double, long double ),
    2348         ?==?( long double, _Complex long double ),
    2349         ?!=?( long double, _Complex long double ),
    2350         ?==?( _Complex long double, _Complex long double ),
    2351         ?!=?( _Complex long double, _Complex long double );
    2352 
     1883int ?==?( int, int ), ?!=?( int, int ),
     1884        ?==?( unsigned int, unsigned int ), ?!=?( unsigned int, unsigned int ),
     1885        ?==?( long int, long int ), ?!=?( long int, long int ),
     1886        ?==?( long unsigned int, long unsigned int ), ?!=?( long unsigned int, long unsigned int ),
     1887        ?==?( long long int, long long int ), ?!=?( long long int, long long int ),
     1888        ?==?( long long unsigned int, long long unsigned int ), ?!=?( long long unsigned int, long long unsigned int ),
     1889        ?==?( float, float ), ?!=?( float, float ),
     1890        ?==?( _Complex float, float ), ?!=?( _Complex float, float ),
     1891        ?==?( float, _Complex float ), ?!=?( float, _Complex float ),
     1892        ?==?( _Complex float, _Complex float ), ?!=?( _Complex float, _Complex float ),
     1893        ?==?( double, double ), ?!=?( double, double ),
     1894        ?==?( _Complex double, double ), ?!=?( _Complex double, double ),
     1895        ?==?( double, _Complex double ), ?!=?( double, _Complex double ),
     1896        ?==?( _Complex double, _Complex double ), ?!=?( _Complex double, _Complex double ),
     1897        ?==?( long double, long double ), ?!=?( long double, long double ),
     1898        ?==?( _Complex long double, long double ), ?!=?( _Complex long double, long double ),
     1899        ?==?( long double, _Complex long double ), ?!=?( long double, _Complex long double ),
     1900        ?==?( _Complex long double, _Complex long double ), ?!=?( _Complex long double, _Complex long double );
    23531901forall( dtype DT ) int
    23541902        ?==?( const restrict volatile DT *, const restrict volatile DT * ),
    … …  
    23751923        ?==?( forall( dtype DT2) const DT2*, _Atomic const restrict volatile DT * ),
    23761924        ?!=?( forall( dtype DT2) const DT2*, _Atomic const restrict volatile DT * );
    2377 
    23781925forall( ftype FT ) int
    2379         ?==?( FT *, FT * ),
    2380         ?!=?( FT *, FT * ),
    2381         ?==?( FT *, forall( ftype FT2) FT2 * ),
    2382         ?!=?( FT *, forall( ftype FT2) FT2 * ),
    2383         ?==?( forall( ftype FT2) FT2*, FT * ),
    2384         ?!=?( forall( ftype FT2) FT2*, FT * ),
    2385         ?==?( forall( ftype FT2) FT2*, forall( ftype FT3) FT3 * ),
    2386         ?!=?( forall( ftype FT2) FT2*, forall( ftype FT3) FT3 * );
    2387 \end{lstlisting}
    2388 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the
    2389 rank of \lstinline$int$ there exist
     1926        ?==?( FT *, FT * ), ?!=?( FT *, FT * ),
     1927        ?==?( FT *, forall( ftype FT2) FT2 * ), ?!=?( FT *, forall( ftype FT2) FT2 * ),
     1928        ?==?( forall( ftype FT2) FT2*, FT * ), ?!=?( forall( ftype FT2) FT2*, FT * ),
     1929        ?==?( forall( ftype FT2) FT2*, forall( ftype FT3) FT3 * ), ?!=?( forall( ftype FT2) FT2*, forall( ftype FT3) FT3 * );
     1930\end{lstlisting}
     1931For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the rank of \lstinline$int$ there exist
    23901932% Don't use predefined: keep this out of prelude.cf.
    23911933\begin{lstlisting}
    … …  
    23951937
    23961938\begin{rationale}
    2397 The polymorphic equality operations come in three styles: comparisons between pointers of compatible
    2398 types, between pointers to \lstinline$void$ and pointers to object types or incomplete types, and
    2399 between the \Index{null pointer} constant and pointers to any type. In the last case, a special
    2400 constraint rule for null pointer constant operands has been replaced by a consequence of the \CFA
    2401 type system.
     1939The polymorphic equality operations come in three styles: comparisons between pointers of compatible types, between pointers to \lstinline$void$ and pointers to object types or incomplete types, and between the \Index{null pointer} constant and pointers to any type.
     1940In the last case, a special constraint rule for null pointer constant operands has been replaced by a consequence of the \CFA type system.
    24021941\end{rationale}
    24031942
    24041943\semantics
    2405 The interpretations of an equality expression are the interpretations of the corresponding function
    2406 call.
     1944The interpretations of an equality expression are the interpretations of the corresponding function call.
    24071945
    24081946\begin{sloppypar}
    2409 The result of an equality comparison between two pointers to predefined functions or predefined
    2410 values is implementation-defined.
     1947The result of an equality comparison between two pointers to predefined functions or predefined values is implementation-defined.
    24111948\end{sloppypar}
    24121949\begin{rationale}
    2413 The implementation-defined status of equality comparisons allows implementations to use one library
    2414 routine to implement many predefined functions. These optimization are particularly important when
    2415 the predefined functions are polymorphic, as is the case for most pointer operations
     1950The implementation-defined status of equality comparisons allows implementations to use one library routine to implement many predefined functions.
     1951These optimization are particularly important when the predefined functions are polymorphic, as is the case for most pointer operations
    24161952\end{rationale}
    24171953
    … …  
    24391975long long unsigned int ?&?( long long unsigned int, long long unsigned int );
    24401976\end{lstlisting}
    2441 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the
    2442 rank of \lstinline$int$ there exist
     1977For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the rank of \lstinline$int$ there exist
    24431978% Don't use predefined: keep this out of prelude.cf.
    24441979\begin{lstlisting}
    … …  
    24471982
    24481983\semantics
    2449 The interpretations of a bitwise AND expression are the interpretations of the corresponding
    2450 function call.
     1984The interpretations of a bitwise AND expression are the interpretations of the corresponding function call.
    24511985
    24521986
    … …  
    24732007long long unsigned int ?^?( long long unsigned int, long long unsigned int );
    24742008\end{lstlisting}
    2475 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the
    2476 rank of \lstinline$int$ there exist
     2009For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the rank of \lstinline$int$ there exist
    24772010% Don't use predefined: keep this out of prelude.cf.
    24782011\begin{lstlisting}
    … …  
    24812014
    24822015\semantics
    2483 The interpretations of a bitwise exclusive OR expression are the interpretations of the
    2484 corresponding function call.
     2016The interpretations of a bitwise exclusive OR expression are the interpretations of the corresponding function call.
    24852017
    24862018
    … …  
    25072039long long unsigned int ?|?( long long unsigned int, long long unsigned int );
    25082040\end{lstlisting}
    2509 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the
    2510 rank of \lstinline$int$ there exist
     2041For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the rank of \lstinline$int$ there exist
    25112042% Don't use predefined: keep this out of prelude.cf.
    25122043\begin{lstlisting}
    … …  
    25152046
    25162047\semantics
    2517 The interpretations of a bitwise inclusive OR expression are the interpretations of the
    2518 corresponding function call.
     2048The interpretations of a bitwise inclusive OR expression are the interpretations of the corresponding function call.
    25192049
    25202050
    … …  
    25282058
    25292059\semantics The operands of the expression ``\lstinline$a && b$'' are treated as
    2530 ``\lstinline$(int)((a)!=0)$'' and ``\lstinline$(int)((b)!=0)$'', which shall both be
    2531 unambiguous. The expression has only one interpretation, which is of type \lstinline$int$.
    2532 \begin{rationale}
    2533 When the operands of a logical expression are values of built-in types, and ``\lstinline$!=$'' has
    2534 not been redefined for those types, the compiler can optimize away the function calls.
     2060``\lstinline$(int)((a)!=0)$'' and ``\lstinline$(int)((b)!=0)$'', which shall both be unambiguous.
     2061The expression has only one interpretation, which is of type \lstinline$int$.
     2062\begin{rationale}
     2063When the operands of a logical expression are values of built-in types, and ``\lstinline$!=$'' has not been redefined for those types, the compiler can optimize away the function calls.
    25352064
    25362065A common C idiom omits comparisons to \lstinline$0$ in the controlling expressions of loops and
    2537 \lstinline$if$ statements. For instance, the loop below iterates as long as \lstinline$rp$ points
    2538 at a \lstinline$Rational$ value that is non-zero.
    2539 
    2540 \begin{lstlisting}
    2541 extern type Rational;@\use{Rational}@
     2066\lstinline$if$ statements.
     2067For instance, the loop below iterates as long as \lstinline$rp$ points at a \lstinline$Rational$ value that is non-zero.
     2068
     2069\begin{lstlisting}
     2070extern otype Rational;@\use{Rational}@
    25422071extern const Rational 0;@\use{0}@
    25432072extern int ?!=?( Rational, Rational );
    25442073Rational *rp;
    2545 
    25462074while ( rp && *rp ) { ... }
    25472075\end{lstlisting}
    2548 The logical expression calls the \lstinline$Rational$ inequality operator, passing
    2549 it \lstinline$*rp$ and the \lstinline$Rational 0$, and getting a 1 or 0 as a result. In
    2550 contrast, {\CC} would apply a programmer-defined \lstinline$Rational$-to-\lstinline$int$
    2551 conversion to \lstinline$*rp$ in the equivalent situation. The conversion to \lstinline$int$ would
    2552 produce a general integer value, which is unfortunate, and possibly dangerous if the conversion was
    2553 not written with this situation in mind.
     2076The logical expression calls the \lstinline$Rational$ inequality operator, passing it \lstinline$*rp$ and the \lstinline$Rational 0$, and getting a 1 or 0 as a result.
     2077In contrast, {\CC} would apply a programmer-defined \lstinline$Rational$-to-\lstinline$int$ conversion to \lstinline$*rp$ in the equivalent situation.
     2078The conversion to \lstinline$int$ would produce a general integer value, which is unfortunate, and possibly dangerous if the conversion was not written with this situation in mind.
    25542079\end{rationale}
    25552080
    … …  
    25652090\semantics
    25662091
    2567 The operands of the expression ``\lstinline$a || b$'' are treated as ``\lstinline$(int)((a)!=0)$''
    2568 and ``\lstinline$(int)((b))!=0)$'', which shall both be unambiguous. The expression has only one
    2569 interpretation, which is of type \lstinline$int$.
     2092The operands of the expression ``\lstinline$a || b$'' are treated as ``\lstinline$(int)((a)!=0)$'' and ``\lstinline$(int)((b))!=0)$'', which shall both be unambiguous.
     2093The expression has only one interpretation, which is of type \lstinline$int$.
    25702094
    25712095
    … …  
    25802104
    25812105\semantics
    2582 In the conditional expression\use{?:} ``\lstinline$a?b:c$'', if the second and
    2583 third operands both have an interpretation with \lstinline$void$ type, then the expression has an
    2584 interpretation with type \lstinline$void$, equivalent to
     2106In the conditional expression\use{?:} ``\lstinline$a?b:c$'', if the second and third operands both have an interpretation with \lstinline$void$ type, then the expression has an interpretation with type \lstinline$void$, equivalent to
    25852107\begin{lstlisting}
    25862108( int)(( a)!=0) ? ( void)( b) : ( void)( c)
    25872109\end{lstlisting}
    25882110
    2589 If the second and third operands both have interpretations with non-\lstinline$void$ types, the
    2590 expression is treated as if it were the call ``\lstinline$cond((a)!=0, b, c)$'',
    2591 with \lstinline$cond$ declared as
    2592 \begin{lstlisting}
    2593 forall( type T ) T cond( int, T, T );
    2594  
    2595 forall( dtype D ) void
    2596         * cond( int, D *, void * ),
    2597         * cond( int, void *, D * );
    2598        
    2599 forall( dtype D ) _atomic void
    2600         * cond( int, _Atomic D *, _Atomic void * ),
    2601         * cond( int, _Atomic void *, _Atomic D * );
    2602 
    2603 forall( dtype D ) const void
    2604         * cond( int, const D *, const void * ),
    2605         * cond( int, const void *, const D * );
    2606 
    2607 forall( dtype D ) restrict void
    2608         * cond( int, restrict D *, restrict void * ),
    2609         * cond( int, restrict void *, restrict D * );
    2610 
    2611 forall( dtype D ) volatile void
    2612         * cond( int, volatile D *, volatile void * ),
    2613         * cond( int, volatile void *, volatile D * );
    2614 
    2615 forall( dtype D ) _Atomic const void
    2616         * cond( int, _Atomic const D *, _Atomic const void * ),
    2617         * cond( int, _Atomic const void *, _Atomic const D * );
    2618 
    2619 forall( dtype D ) _Atomic restrict void
    2620         * cond( int, _Atomic restrict D *, _Atomic restrict void * ),
    2621         * cond( int, _Atomic restrict void *, _Atomic restrict D * );
    2622 
    2623 forall( dtype D ) _Atomic volatile void
    2624         * cond( int, _Atomic volatile D *, _Atomic volatile void * ),
    2625         * cond( int, _Atomic volatile void *, _Atomic volatile D * );
    2626 
    2627 forall( dtype D ) const restrict void
    2628         * cond( int, const restrict D *, const restrict void * ),
    2629         * cond( int, const restrict void *, const restrict D * );
    2630 
    2631 forall( dtype D ) const volatile void
    2632         * cond( int, const volatile D *, const volatile void * ),
    2633         * cond( int, const volatile void *, const volatile D * );
    2634 
    2635 forall( dtype D ) restrict volatile void
    2636         * cond( int, restrict volatile D *, restrict volatile void * ),
    2637         * cond( int, restrict volatile void *, restrict volatile D * );
    2638 
    2639 forall( dtype D ) _Atomic const restrict void
    2640         * cond( int, _Atomic const restrict D *, _Atomic const restrict void * ),
     2111If the second and third operands both have interpretations with non-\lstinline$void$ types, the expression is treated as if it were the call ``\lstinline$cond((a)!=0, b, c)$'', with \lstinline$cond$ declared as
     2112\begin{lstlisting}
     2113forall( otype T ) T cond( int, T, T );
     2114forall( dtype D ) void * cond( int, D *, void * ), * cond( int, void *, D * );
     2115forall( dtype D ) _atomic void * cond(
     2116        int, _Atomic D *, _Atomic void * ), * cond( int, _Atomic void *, _Atomic D * );
     2117forall( dtype D ) const void * cond(
     2118        int, const D *, const void * ), * cond( int, const void *, const D * );
     2119forall( dtype D ) restrict void * cond(
     2120        int, restrict D *, restrict void * ), * cond( int, restrict void *, restrict D * );
     2121forall( dtype D ) volatile void * cond(
     2122        int, volatile D *, volatile void * ), * cond( int, volatile void *, volatile D * );
     2123forall( dtype D ) _Atomic const void * cond(
     2124        int, _Atomic const D *, _Atomic const void * ), * cond( int, _Atomic const void *, _Atomic const D * );
     2125forall( dtype D ) _Atomic restrict void * cond(
     2126        int, _Atomic restrict D *, _Atomic restrict void * ), * cond( int, _Atomic restrict void *, _Atomic restrict D * );
     2127forall( dtype D ) _Atomic volatile void * cond(
     2128        int, _Atomic volatile D *, _Atomic volatile void * ), * cond( int, _Atomic volatile void *, _Atomic volatile D * );
     2129forall( dtype D ) const restrict void * cond(
     2130        int, const restrict D *, const restrict void * ), * cond( int, const restrict void *, const restrict D * );
     2131forall( dtype D ) const volatile void * cond(
     2132        int, const volatile D *, const volatile void * ), * cond( int, const volatile void *, const volatile D * );
     2133forall( dtype D ) restrict volatile void * cond(
     2134        int, restrict volatile D *, restrict volatile void * ), * cond( int, restrict volatile void *, restrict volatile D * );
     2135forall( dtype D ) _Atomic const restrict void * cond(
     2136        int, _Atomic const restrict D *, _Atomic const restrict void * ),
    26412137        * cond( int, _Atomic const restrict void *, _Atomic const restrict D * );
    2642 
    2643 forall( dtype D ) _Atomic const volatile void
    2644         * cond( int, _Atomic const volatile D *, _Atomic const volatile void * ),
     2138forall( dtype D ) _Atomic const volatile void * cond(
     2139        int, _Atomic const volatile D *, _Atomic const volatile void * ),
    26452140        * cond( int, _Atomic const volatile void *, _Atomic const volatile D * );
    2646 
    2647 forall( dtype D ) _Atomic restrict volatile void
    2648         * cond( int, _Atomic restrict volatile D *,
    2649          _Atomic restrict volatile void * ),
    2650         * cond( int, _Atomic restrict volatile void *,
    2651          _Atomic restrict volatile D * );
    2652 
    2653 forall( dtype D ) const restrict volatile void
    2654         * cond( int, const restrict volatile D *,
    2655          const restrict volatile void * ),
    2656         * cond( int, const restrict volatile void *,
    2657          const restrict volatile D * );
    2658 
    2659 forall( dtype D ) _Atomic const restrict volatile void
    2660         * cond( int, _Atomic const restrict volatile D *,
    2661          _Atomic const restrict volatile void * ),
    2662         * cond( int, _Atomic const restrict volatile void *,
    2663          _Atomic const restrict volatile D * );
    2664 \end{lstlisting}
    2665 
    2666 \begin{rationale}
    2667 The object of the above is to apply the \Index{usual arithmetic conversion}s when the second and
    2668 third operands have arithmetic type, and to combine the qualifiers of the second and third operands
    2669 if they are pointers.
     2141forall( dtype D ) _Atomic restrict volatile void * cond(
     2142        int, _Atomic restrict volatile D *, _Atomic restrict volatile void * ),
     2143        * cond( int, _Atomic restrict volatile void *, _Atomic restrict volatile D * );
     2144forall( dtype D ) const restrict volatile void * cond(
     2145        int, const restrict volatile D *, const restrict volatile void * ),
     2146        * cond( int, const restrict volatile void *, const restrict volatile D * );
     2147forall( dtype D ) _Atomic const restrict volatile void * cond(
     2148        int, _Atomic const restrict volatile D *, _Atomic const restrict volatile void * ),
     2149        * cond( int, _Atomic const restrict volatile void *, _Atomic const restrict volatile D * );
     2150\end{lstlisting}
     2151
     2152\begin{rationale}
     2153The object of the above is to apply the \Index{usual arithmetic conversion}s when the second and third operands have arithmetic type, and to combine the qualifiers of the second and third operands if they are pointers.
    26702154\end{rationale}
    26712155
    … …  
    26852169rand() ? cip : vip;
    26862170\end{lstlisting}
    2687 The expression has type \lstinline$const volatile int *$, with safe conversions applied to the second
    2688 and third operands to add \lstinline$volatile$ and \lstinline$const$ qualifiers, respectively.
     2171The expression has type \lstinline$const volatile int *$, with safe conversions applied to the second and third operands to add \lstinline$volatile$ and \lstinline$const$ qualifiers, respectively.
    26892172
    26902173\begin{lstlisting}
    … …  
    27082191
    27092192\rewriterules
    2710 Let ``\(\leftarrow\)'' be any of the assignment operators. Then
     2193Let ``\(\leftarrow\)'' be any of the assignment operators.
     2194Then
    27112195\use{?=?}\use{?*=?}\use{?/=?}\use{?%=?}\use{?+=?}\use{?-=?}
    27122196\use{?>>=?}\use{?&=?}\use{?^=?}\use{?"|=?}%use{?<<=?}
    … …  
    27162200
    27172201\semantics
    2718 Each interpretation of the left operand of an assignment expression is considered separately. For
    2719 each interpretation that is a bit-field or is declared with the \lstinline$register$ storage class
    2720 specifier, the expression has one valid interpretation, with the type of the left operand. The
    2721 right operand is cast to that type, and the assignment expression is ambiguous if either operand is.
    2722 For the remaining interpretations, the expression is rewritten, and the interpretations of the
    2723 assignment expression are the interpretations of the corresponding function call. Finally, all
    2724 interpretations of the expression produced for the different interpretations of the left operand are
    2725 combined to produce the interpretations of the expression as a whole; where interpretations have
    2726 compatible result types, the best interpretations are selected in the manner described for function
    2727 call expressions.
     2202Each interpretation of the left operand of an assignment expression is considered separately.
     2203For each interpretation that is a bit-field or is declared with the \lstinline$register$ storage class specifier, the expression has one valid interpretation, with the type of the left operand.
     2204The right operand is cast to that type, and the assignment expression is ambiguous if either operand is.
     2205For the remaining interpretations, the expression is rewritten, and the interpretations of the assignment expression are the interpretations of the corresponding function call.
     2206Finally, all interpretations of the expression produced for the different interpretations of the left operand are combined to produce the interpretations of the expression as a whole;
     2207where interpretations have compatible result types, the best interpretations are selected in the manner described for function call expressions.
    27282208
    27292209
    … …  
    27902270        ?=?( volatile _Complex long double *, _Complex long double ),
    27912271        ?=?( _Atomic volatile _Complex long double *, _Atomic _Complex long double );
    2792 
    27932272forall( ftype FT ) FT
    27942273        * ?=?( FT * volatile *, FT * ),
    27952274        * ?=?( FT * volatile *, forall( ftype F ) F * );
    2796 
    27972275forall( ftype FT ) FT const
    27982276        * ?=?( FT const * volatile *, FT const * ),
    27992277        * ?=?( FT const * volatile *, forall( ftype F ) F * );
    2800 
    28012278forall( ftype FT ) FT volatile
    28022279        * ?=?( FT volatile * volatile *, FT * ),
    28032280        * ?=?( FT volatile * volatile *, forall( ftype F ) F * );
    2804 
    28052281forall( ftype FT ) FT const
    28062282        * ?=?( FT const volatile * volatile *, FT const * ),
    28072283        * ?=?( FT const volatile * volatile *, forall( ftype F ) F * );
    2808 
    28092284forall( dtype DT ) DT
    28102285        * ?=?( DT * restrict volatile *, DT * ),
    … …  
    28142289        * ?=?( DT * _Atomic restrict volatile *, void * ),
    28152290        * ?=?( DT * _Atomic restrict volatile *, forall( dtype D ) D * );
    2816 
    28172291forall( dtype DT ) DT _Atomic
    28182292        * ?=?( _Atomic DT * restrict volatile *, DT _Atomic * ),
    … …  
    28222296        * ?=?( _Atomic DT * _Atomic restrict volatile *, void * ),
    28232297        * ?=?( _Atomic DT * _Atomic restrict volatile *, forall( dtype D ) D * );
    2824 
    28252298forall( dtype DT ) DT const
    28262299        * ?=?( DT const * restrict volatile *, DT const * ),
    … …  
    28302303        * ?=?( DT const * _Atomic restrict volatile *, void const * ),
    28312304        * ?=?( DT const * _Atomic restrict volatile *, forall( dtype D ) D * );
    2832 
    28332305forall( dtype DT ) DT restrict
    28342306        * ?=?( restrict DT * restrict volatile *, DT restrict * ),
    … …  
    28382310        * ?=?( restrict DT * _Atomic restrict volatile *, void * ),
    28392311        * ?=?( restrict DT * _Atomic restrict volatile *, forall( dtype D ) D * );
    2840 
    28412312forall( dtype DT ) DT volatile
    28422313        * ?=?( DT volatile * restrict volatile *, DT volatile * ),
    … …  
    28462317        * ?=?( DT volatile * _Atomic restrict volatile *, void volatile * ),
    28472318        * ?=?( DT volatile * _Atomic restrict volatile *, forall( dtype D ) D * );
    2848 
    28492319forall( dtype DT ) DT _Atomic const
    28502320        * ?=?( DT _Atomic const * restrict volatile *, DT _Atomic const * ),
    … …  
    28542324        * ?=?( DT _Atomic const * _Atomic restrict volatile *, void const * ),
    28552325        * ?=?( DT _Atomic const * _Atomic restrict volatile *, forall( dtype D ) D * );
    2856 
    28572326forall( dtype DT ) DT _Atomic restrict
    28582327        * ?=?( _Atomic restrict DT * restrict volatile *, DT _Atomic restrict * ),
    … …  
    28622331        * ?=?( _Atomic restrict DT * _Atomic restrict volatile *, void * ),
    28632332        * ?=?( _Atomic restrict DT * _Atomic restrict volatile *, forall( dtype D ) D * );
    2864 
    28652333forall( dtype DT ) DT _Atomic volatile
    28662334        * ?=?( DT _Atomic volatile * restrict volatile *, DT _Atomic volatile * ),
    … …  
    28702338        * ?=?( DT _Atomic volatile * _Atomic restrict volatile *, void volatile * ),
    28712339        * ?=?( DT _Atomic volatile * _Atomic restrict volatile *, forall( dtype D ) D * );
    2872 
    28732340forall( dtype DT ) DT const restrict
    28742341        * ?=?( DT const restrict * restrict volatile *, DT const restrict * ),
    … …  
    28782345        * ?=?( DT const restrict * _Atomic restrict volatile *, void const * ),
    28792346        * ?=?( DT const restrict * _Atomic restrict volatile *, forall( dtype D ) D * );
    2880 
    28812347forall( dtype DT ) DT const volatile
    28822348        * ?=?( DT const volatile * restrict volatile *, DT const volatile * ),
    … …  
    28862352        * ?=?( DT const volatile * _Atomic restrict volatile *, void const volatile * ),
    28872353        * ?=?( DT const volatile * _Atomic restrict volatile *, forall( dtype D ) D * );
    2888 
    28892354forall( dtype DT ) DT restrict volatile
    28902355        * ?=?( DT restrict volatile * restrict volatile *, DT restrict volatile * ),
    … …  
    28942359        * ?=?( DT restrict volatile * _Atomic restrict volatile *, void volatile * ),
    28952360        * ?=?( DT restrict volatile * _Atomic restrict volatile *, forall( dtype D ) D * );
    2896 
    28972361forall( dtype DT ) DT _Atomic const restrict
    28982362        * ?=?( DT _Atomic const restrict * restrict volatile *,
    … …  
    29082372        * ?=?( DT _Atomic const restrict * _Atomic restrict volatile *,
    29092373         forall( dtype D ) D * );
    2910 
    29112374forall( dtype DT ) DT _Atomic const volatile
    29122375        * ?=?( DT _Atomic const volatile * restrict volatile *,
    … …  
    29222385        * ?=?( DT _Atomic const volatile * _Atomic restrict volatile *,
    29232386         forall( dtype D ) D * );
    2924 
    29252387forall( dtype DT ) DT _Atomic restrict volatile
    29262388        * ?=?( DT _Atomic restrict volatile * restrict volatile *,
    … …  
    29362398        * ?=?( DT _Atomic restrict volatile * _Atomic restrict volatile *,
    29372399         forall( dtype D ) D * );
    2938 
    29392400forall( dtype DT ) DT const restrict volatile
    29402401        * ?=?( DT const restrict volatile * restrict volatile *,
    … …  
    29502411        * ?=?( DT const restrict volatile * _Atomic restrict volatile *,
    29512412         forall( dtype D ) D * );
    2952 
    29532413forall( dtype DT ) DT _Atomic const restrict volatile
    29542414        * ?=?( DT _Atomic const restrict volatile * restrict volatile *,
    … …  
    29642424        * ?=?( DT _Atomic const restrict volatile * _Atomic restrict volatile *,
    29652425         forall( dtype D ) D * );
    2966 
    29672426forall( dtype DT ) void
    29682427        * ?=?( void * restrict volatile *, DT * );
    2969 
    29702428forall( dtype DT ) void const
    29712429        * ?=?( void const * restrict volatile *, DT const * );
    2972 
    29732430forall( dtype DT ) void volatile
    29742431        * ?=?( void volatile * restrict volatile *, DT volatile * );
    2975 
    29762432forall( dtype DT ) void const volatile
    29772433        * ?=?( void const volatile * restrict volatile *, DT const volatile * );
    29782434\end{lstlisting}
    29792435\begin{rationale}
    2980 The pattern of overloadings for simple assignment resembles that of pointer increment and decrement,
    2981 except that the polymorphic pointer assignment functions declare a \lstinline$dtype$ parameter,
    2982 instead of a \lstinline$type$ parameter, because the left operand may be a pointer to an incomplete
    2983 type.
     2436The pattern of overloadings for simple assignment resembles that of pointer increment and decrement, except that the polymorphic pointer assignment functions declare a \lstinline$dtype$ parameter, instead of a \lstinline$type$ parameter, because the left operand may be a pointer to an incomplete type.
    29842437\end{rationale}
    29852438
    … …  
    30062459
    30072460\semantics
    3008 The structure assignment functions provide member-wise assignment; each non-array member and each
    3009 element of each array member of the right argument is assigned to the corresponding member or
    3010 element of the left argument using the assignment function defined for its type. All other
    3011 assignment functions have the same effect as the corresponding C assignment expression.
    3012 \begin{rationale}
    3013 Note that, by default, union assignment\index{deficiencies!union assignment} uses C semantics---that
    3014 is, bitwise copy---even if some of the union members have programmer-defined assignment functions.
     2461The structure assignment functions provide member-wise assignment;
     2462each non-array member and each element of each array member of the right argument is assigned to the corresponding member or element of the left argument using the assignment function defined for its type.
     2463All other assignment functions have the same effect as the corresponding C assignment expression.
     2464\begin{rationale}
     2465Note that, by default, union assignment\index{deficiencies!union assignment} uses C semantics---that is, bitwise copy---even if some of the union members have programmer-defined assignment functions.
    30152466\end{rationale}
    30162467
    … …  
    30202471\predefined
    30212472\begin{lstlisting}
    3022 forall( type T ) T
     2473forall( otype T ) T
    30232474        * ?+=?( T * restrict volatile *, ptrdiff_t ),
    30242475        * ?-=?( T * restrict volatile *, ptrdiff_t ),
    30252476        * ?+=?( T * _Atomic restrict volatile *, ptrdiff_t ),
    30262477        * ?-=?( T * _Atomic restrict volatile *, ptrdiff_t );
    3027 
    3028 forall( type T ) T _Atomic
     2478forall( otype T ) T _Atomic
    30292479        * ?+=?( T _Atomic * restrict volatile *, ptrdiff_t ),
    30302480        * ?-=?( T _Atomic * restrict volatile *, ptrdiff_t ),
    30312481        * ?+=?( T _Atomic * _Atomic restrict volatile *, ptrdiff_t ),
    30322482        * ?-=?( T _Atomic * _Atomic restrict volatile *, ptrdiff_t );
    3033 
    3034 forall( type T ) T const
     2483forall( otype T ) T const
    30352484        * ?+=?( T const * restrict volatile *, ptrdiff_t ),
    30362485        * ?-=?( T const * restrict volatile *, ptrdiff_t ),
    30372486        * ?+=?( T const * _Atomic restrict volatile *, ptrdiff_t ),
    30382487        * ?-=?( T const * _Atomic restrict volatile *, ptrdiff_t );
    3039 
    3040 forall( type T ) T restrict
     2488forall( otype T ) T restrict
    30412489        * ?+=?( T restrict * restrict volatile *, ptrdiff_t ),
    30422490        * ?-=?( T restrict * restrict volatile *, ptrdiff_t ),
    30432491        * ?+=?( T restrict * _Atomic restrict volatile *, ptrdiff_t ),
    30442492        * ?-=?( T restrict * _Atomic restrict volatile *, ptrdiff_t );
    3045 
    3046 forall( type T ) T volatile
     2493forall( otype T ) T volatile
    30472494        * ?+=?( T volatile * restrict volatile *, ptrdiff_t ),
    30482495        * ?-=?( T volatile * restrict volatile *, ptrdiff_t ),
    30492496        * ?+=?( T volatile * _Atomic restrict volatile *, ptrdiff_t ),
    30502497        * ?-=?( T volatile * _Atomic restrict volatile *, ptrdiff_t );
    3051 
    3052 forall( type T ) T _Atomic const
     2498forall( otype T ) T _Atomic const
    30532499        * ?+=?( T _Atomic const restrict volatile *, ptrdiff_t ),
    30542500        * ?-=?( T _Atomic const restrict volatile *, ptrdiff_t ),
    30552501        * ?+=?( T _Atomic const _Atomic restrict volatile *, ptrdiff_t ),
    30562502        * ?-=?( T _Atomic const _Atomic restrict volatile *, ptrdiff_t );
    3057 
    3058 forall( type T ) T _Atomic restrict
     2503forall( otype T ) T _Atomic restrict
    30592504        * ?+=?( T _Atomic restrict * restrict volatile *, ptrdiff_t ),
    30602505        * ?-=?( T _Atomic restrict * restrict volatile *, ptrdiff_t ),
    30612506        * ?+=?( T _Atomic restrict * _Atomic restrict volatile *, ptrdiff_t ),
    30622507        * ?-=?( T _Atomic restrict * _Atomic restrict volatile *, ptrdiff_t );
    3063 
    3064 forall( type T ) T _Atomic volatile
     2508forall( otype T ) T _Atomic volatile
    30652509        * ?+=?( T _Atomic volatile * restrict volatile *, ptrdiff_t ),
    30662510        * ?-=?( T _Atomic volatile * restrict volatile *, ptrdiff_t ),
    30672511        * ?+=?( T _Atomic volatile * _Atomic restrict volatile *, ptrdiff_t ),
    30682512        * ?-=?( T _Atomic volatile * _Atomic restrict volatile *, ptrdiff_t );
    3069 
    3070 forall( type T ) T const restrict
     2513forall( otype T ) T const restrict
    30712514        * ?+=?( T const restrict * restrict volatile *, ptrdiff_t ),
    30722515        * ?-=?( T const restrict * restrict volatile *, ptrdiff_t ),
    30732516        * ?+=?( T const restrict * _Atomic restrict volatile *, ptrdiff_t ),
    30742517        * ?-=?( T const restrict * _Atomic restrict volatile *, ptrdiff_t );
    3075 
    3076 forall( type T ) T const volatile
     2518forall( otype T ) T const volatile
    30772519        * ?+=?( T const volatile * restrict volatile *, ptrdiff_t ),
    30782520        * ?-=?( T const volatile * restrict volatile *, ptrdiff_t ),
    30792521        * ?+=?( T const volatile * _Atomic restrict volatile *, ptrdiff_t ),
    30802522        * ?-=?( T const volatile * _Atomic restrict volatile *, ptrdiff_t );
    3081 
    3082 forall( type T ) T restrict volatile
     2523forall( otype T ) T restrict volatile
    30832524        * ?+=?( T restrict volatile * restrict volatile *, ptrdiff_t ),
    30842525        * ?-=?( T restrict volatile * restrict volatile *, ptrdiff_t ),
    30852526        * ?+=?( T restrict volatile * _Atomic restrict volatile *, ptrdiff_t ),
    30862527        * ?-=?( T restrict volatile * _Atomic restrict volatile *, ptrdiff_t );
    3087 
    3088 forall( type T ) T _Atomic const restrict
     2528forall( otype T ) T _Atomic const restrict
    30892529        * ?+=?( T _Atomic const restrict * restrict volatile *, ptrdiff_t ),
    30902530        * ?-=?( T _Atomic const restrict * restrict volatile *, ptrdiff_t ),
    30912531        * ?+=?( T _Atomic const restrict * _Atomic restrict volatile *, ptrdiff_t ),
    30922532        * ?-=?( T _Atomic const restrict * _Atomic restrict volatile *, ptrdiff_t );
    3093 
    3094 forall( type T ) T _Atomic const volatile
     2533forall( otype T ) T _Atomic const volatile
    30952534        * ?+=?( T _Atomic const volatile * restrict volatile *, ptrdiff_t ),
    30962535        * ?-=?( T _Atomic const volatile * restrict volatile *, ptrdiff_t ),
    30972536        * ?+=?( T _Atomic const volatile * _Atomic restrict volatile *, ptrdiff_t ),
    30982537        * ?-=?( T _Atomic const volatile * _Atomic restrict volatile *, ptrdiff_t );
    3099 
    3100 forall( type T ) T _Atomic restrict volatile
     2538forall( otype T ) T _Atomic restrict volatile
    31012539        * ?+=?( T _Atomic restrict volatile * restrict volatile *, ptrdiff_t ),
    31022540        * ?-=?( T _Atomic restrict volatile * restrict volatile *, ptrdiff_t ),
    31032541        * ?+=?( T _Atomic restrict volatile * _Atomic restrict volatile *, ptrdiff_t ),
    31042542        * ?-=?( T _Atomic restrict volatile * _Atomic restrict volatile *, ptrdiff_t );
    3105 
    3106 forall( type T ) T const restrict volatile
     2543forall( otype T ) T const restrict volatile
    31072544        * ?+=?( T const restrict volatile * restrict volatile *, ptrdiff_t ),
    31082545        * ?-=?( T const restrict volatile * restrict volatile *, ptrdiff_t ),
    31092546        * ?+=?( T const restrict volatile * _Atomic restrict volatile *, ptrdiff_t ),
    31102547        * ?-=?( T const restrict volatile * _Atomic restrict volatile *, ptrdiff_t );
    3111 
    3112 forall( type T ) T _Atomic const restrict volatile
     2548forall( otype T ) T _Atomic const restrict volatile
    31132549        * ?+=?( T _Atomic const restrict volatile * restrict volatile *, ptrdiff_t ),
    31142550        * ?-=?( T _Atomic const restrict volatile * restrict volatile *, ptrdiff_t ),
    … …  
    33212757\semantics
    33222758In the comma expression ``\lstinline$a, b$'', the first operand is interpreted as
    3323 ``\lstinline$( void )(a)$'', which shall be unambiguous\index{ambiguous interpretation}. The
    3324 interpretations of the expression are the interpretations of the second operand.
     2759``\lstinline$( void )(a)$'', which shall be unambiguous\index{ambiguous interpretation}.
     2760The interpretations of the expression are the interpretations of the second operand.
    33252761
    33262762
    … …  
    33372773
    33382774\constraints
    3339 If an identifier has \Index{no linkage}, there shall be no more than one declaration of the
    3340 identifier ( in a declarator or type specifier ) with compatible types in the same scope and in the
    3341 same name space, except that:
     2775If an identifier has \Index{no linkage}, there shall be no more than one declaration of the identifier ( in a declarator or type specifier ) with compatible types in the same scope and in the same name space, except that:
    33422776\begin{itemize}
    3343 \item
    3344 a typedef name may be redefined to denote the same type as it currently does, provided that type is
    3345 not a variably modified type;
    3346 \item
    3347 tags may be redeclared as specified in section 6.7.2.3 of the {\c11} standard.
     2777\item a typedef name may be redefined to denote the same type as it currently does, provided that type is not a variably modified type;
     2778\item tags may be redeclared as specified in section 6.7.2.3 of the {\c11} standard.
    33482779\end{itemize}
    33492780\begin{rationale}
    3350 This constraint adds the phrase ``with compatible types'' to the {\c11} constraint, to allow
    3351 overloading.
    3352 \end{rationale}
    3353 
    3354 An identifier declared by a type declaration shall not be redeclared as a parameter in a function
    3355 definition whose declarator includes an identifier list.
    3356 \begin{rationale}
    3357 This restriction echos {\c11}'s ban on the redeclaration of typedef names as parameters. This
    3358 avoids an ambiguity between old-style function declarations and new-style function prototypes:
     2781This constraint adds the phrase ``with compatible types'' to the {\c11} constraint, to allow overloading.
     2782\end{rationale}
     2783
     2784An identifier declared by a type declaration shall not be redeclared as a parameter in a function definition whose declarator includes an identifier list.
     2785\begin{rationale}
     2786This restriction echos {\c11}'s ban on the redeclaration of typedef names as parameters.
     2787This avoids an ambiguity between old-style function declarations and new-style function prototypes:
    33592788\begin{lstlisting}
    33602789void f( Complex,        // ... 3000 characters ...
    33612790void g( Complex,        // ... 3000 characters ...
    3362 int Complex; { ... }
    3363 \end{lstlisting}
    3364 Without the rule, \lstinline$Complex$ would be a type in the first case, and a parameter name in the
    3365 second.
     2791int Complex;
     2792{ ... }
     2793\end{lstlisting}
     2794Without the rule, \lstinline$Complex$ would be a type in the first case, and a parameter name in the second.
    33662795\end{rationale}
    33672796
    … …  
    33822811
    33832812\semantics
    3384 \CFA extends the {\c11} definition of \define{anonymous structure} to include structure
    3385 specifiers with tags, and extends the {\c11} definition of \define{anonymous union} to include union
    3386 specifiers with tags.
     2813\CFA extends the {\c11} definition of \define{anonymous structure} to include structure specifiers with tags, and extends the {\c11} definition of \define{anonymous union} to include union specifiers with tags.
    33872814\begin{rationale}
    33882815This extension imitates an extension in the Plan 9 C compiler \cite{Thompson90new}.
    … …  
    34012828cp.x = 0;
    34022829cp.color = RED;
    3403 
    34042830struct literal {@\impl{literal}@
    34052831        enum { NUMBER, STRING } tag;
    34062832        union {
    3407          double n;
    3408          char *s;
     2833                double n;
     2834                char *s;
    34092835        };
    34102836};
    … …  
    34282854\begin{comment}
    34292855\constraints
    3430 If the \nonterm{declaration-specifiers} of a declaration that contains a \nonterm{forall-specifier}
    3431 declares a structure or union tag, the types of the members of the structure or union shall not use
    3432 any of the type identifiers declared by the \nonterm{type-parameter-list}.
    3433 \begin{rationale}
    3434 This sort of declaration is illegal because the scope of the type identifiers ends at the end of the
    3435 declaration, but the scope of the structure tag does not.
    3436 \begin{lstlisting}
    3437 forall( type T ) struct Pair { T a, b; } mkPair( T, T ); // illegal
    3438 \end{lstlisting}
    3439 If an instance of \lstinline$struct Pair$ was declared later in the current scope, what would the
    3440 members' type be?
     2856If the \nonterm{declaration-specifiers} of a declaration that contains a \nonterm{forall-specifier} declares a structure or union tag, the types of the members of the structure or union shall not use any of the type identifiers declared by the \nonterm{type-parameter-list}.
     2857\begin{rationale}
     2858This sort of declaration is illegal because the scope of the type identifiers ends at the end of the declaration, but the scope of the structure tag does not.
     2859\begin{lstlisting}
     2860forall( otype T ) struct Pair { T a, b;
     2861} mkPair( T, T ); // illegal
     2862\end{lstlisting}
     2863If an instance of \lstinline$struct Pair$ was declared later in the current scope, what would the members' type be?
    34412864\end{rationale}
    34422865\end{comment}
    34432866
    34442867\semantics
    3445 The \nonterm{type-parameter-list}s and assertions of the \nonterm{forall-specifier}s declare type
    3446 identifiers, function and object identifiers with \Index{no linkage}.
     2868The \nonterm{type-parameter-list}s and assertions of the \nonterm{forall-specifier}s declare type identifiers, function and object identifiers with \Index{no linkage}.
    34472869
    34482870If, in the declaration ``\lstinline$T D$'', \lstinline$T$ contains \nonterm{forall-specifier}s and
    … …  
    34502872\begin{lstlisting}
    34512873D( @\normalsize\nonterm{parameter-type-list}@ )
    3452 \end{lstlisting}
    3453 then a type identifier declared by one of the \nonterm{forall-specifier}s is an \define{inferred
    3454 parameter} of the function declarator if and only if it is not an inferred parameter of a function
    3455 declarator in \lstinline$D$, and it is used in the type of a parameter in the following
     2874\end{lstlisting} then a type identifier declared by one of the \nonterm{forall-specifier}s is an \define{inferred parameter} of the function declarator if and only if it is not an inferred parameter of a function declarator in \lstinline$D$, and it is used in the type of a parameter in the following
    34562875\nonterm{type-parameter-list} or it and an inferred parameter are used as arguments of a
    3457 \Index{specification} in one of the \nonterm{forall-specifier}s. The identifiers declared by
    3458 assertions that use an inferred parameter of a function declarator are \Index{assertion parameter}s
    3459 of that function declarator.
     2876\Index{specification} in one of the \nonterm{forall-specifier}s.
     2877The identifiers declared by assertions that use an inferred parameter of a function declarator are \Index{assertion parameter}s of that function declarator.
    34602878
    34612879\begin{comment}
    34622880\begin{rationale}
    3463 Since every inferred parameter is used by some parameter, inference can be understood as a single
    3464 bottom-up pass over the expression tree, that only needs to apply local reasoning at each node.
     2881Since every inferred parameter is used by some parameter, inference can be understood as a single bottom-up pass over the expression tree, that only needs to apply local reasoning at each node.
    34652882
    34662883If this restriction were lifted, it would be possible to write
    34672884\begin{lstlisting}
    3468 forall( type T ) T * alloc( void );@\use{alloc}@
    3469 int *p = alloc();
     2885forall( otype T ) T * alloc( void );@\use{alloc}@ int *p = alloc();
    34702886\end{lstlisting}
    34712887Here \lstinline$alloc()$ would receive \lstinline$int$ as an inferred argument, and return an
    3472 \lstinline$int *$. In general, if a call to \lstinline$alloc()$ is a subexpression of an expression
    3473 involving polymorphic functions and overloaded identifiers, there could be considerable distance
    3474 between the call and the subexpression that causes \lstinline$T$ to be bound.
     2888\lstinline$int *$.
     2889In general, if a call to \lstinline$alloc()$ is a subexpression of an expression involving polymorphic functions and overloaded identifiers, there could be considerable distance between the call and the subexpression that causes \lstinline$T$ to be bound.
    34752890
    34762891With the current restriction, \lstinline$alloc()$ must be given an argument that determines
    34772892\lstinline$T$:
    34782893\begin{lstlisting}
    3479 forall( type T ) T * alloc( T initial_value );@\use{alloc}@
     2894forall( otype T ) T * alloc( T initial_value );@\use{alloc}@
    34802895\end{lstlisting}
    34812896\end{rationale}
    34822897\end{comment}
    34832898
    3484 If a function declarator is part of a function definition, its inferred parameters and assertion
    3485 parameters have \Index{block scope}; otherwise, identifiers declared by assertions have a
     2899If a function declarator is part of a function definition, its inferred parameters and assertion parameters have \Index{block scope};
     2900otherwise, identifiers declared by assertions have a
    34862901\define{declaration scope}, which terminates at the end of the \nonterm{declaration}.
    34872902
    34882903A function type that has at least one inferred parameter is a \define{polymorphic function} type.
    3489 Function types with no inferred parameters are \define{monomorphic function} types. One function
    3490 type is \define{less polymorphic} than another if it has fewer inferred parameters, or if it has the
    3491 same number of inferred parameters and fewer of its explicit parameters have types that depend on an
    3492 inferred parameter.
    3493 
    3494 The names of inferred parameters and the order of identifiers in forall specifiers are not relevant
    3495 to polymorphic function type compatibility. Let $f$ and $g$ be two polymorphic function types with
    3496 the same number of inferred parameters, and let $f_i$ and $g_i$ be the inferred parameters of $f$
    3497 and $g$ in their order of occurance in the function types' \nonterm{parameter-type-list}s. Let $f'$
    3498 be $f$ with every occurrence of $f_i$ replaced by $g_i$, for all $i$. Then $f$ and $g$ are
    3499 \Index{compatible type}s if $f'$'s and $g$'s return types and parameter lists are compatible, and if
    3500 for every assertion parameter of $f'$ there is an assertion parameter in $g$ with the same
    3501 identifier and compatible type, and vice versa.
     2904Function types with no inferred parameters are \define{monomorphic function} types.
     2905One function type is \define{less polymorphic} than another if it has fewer inferred parameters, or if it has the same number of inferred parameters and fewer of its explicit parameters have types that depend on an inferred parameter.
     2906
     2907The names of inferred parameters and the order of identifiers in forall specifiers are not relevant to polymorphic function type compatibility.
     2908Let $f$ and $g$ be two polymorphic function types with the same number of inferred parameters, and let $f_i$ and $g_i$ be the inferred parameters of $f$ and $g$ in their order of occurance in the function types' \nonterm{parameter-type-list}s.
     2909Let $f'$ be $f$ with every occurrence of $f_i$ replaced by $g_i$, for all $i$.
     2910Then $f$ and $g$ are
     2911\Index{compatible type}s if $f'$'s and $g$'s return types and parameter lists are compatible, and if for every assertion parameter of $f'$ there is an assertion parameter in $g$ with the same identifier and compatible type, and vice versa.
    35022912
    35032913\examples
    … …  
    35052915\begin{lstlisting}
    35062916int fi( int );
    3507 forall( type T ) T fT( T );
     2917forall( otype T ) T fT( T );
    35082918\end{lstlisting}
    35092919\lstinline$fi()$ takes an \lstinline$int$ and returns an \lstinline$int$. \lstinline$fT()$ takes a
    … …  
    35112921\begin{lstlisting}
    35122922int (*pfi )( int ) = fi;
    3513 forall( type T ) T (*pfT )( T ) = fT;
    3514 \end{lstlisting}
    3515 \lstinline$pfi$ and \lstinline$pfT$ are pointers to functions. \lstinline$pfT$ is not
    3516 polymorphic, but the function it points at is.
     2923forall( otype T ) T (*pfT )( T ) = fT;
     2924\end{lstlisting}
     2925\lstinline$pfi$ and \lstinline$pfT$ are pointers to functions. \lstinline$pfT$ is not polymorphic, but the function it points at is.
    35172926\begin{lstlisting}
    35182927int (*fvpfi( void ))( int ) {
    35192928        return pfi;
    35202929}
    3521 forall( type T ) T (*fvpfT( void ))( T ) {
     2930forall( otype T ) T (*fvpfT( void ))( T ) {
    35222931        return pfT;
    35232932}
    35242933\end{lstlisting}
    3525 \lstinline$fvpfi()$ and \lstinline$fvpfT()$ are functions taking no arguments and returning pointers
    3526 to functions. \lstinline$fvpfT()$ is monomorphic, but the function that its return value points
    3527 at is polymorphic.
    3528 \begin{lstlisting}
    3529 forall( type T ) int ( *fTpfi( T ) )( int );
    3530 forall( type T ) T ( *fTpfT( T ) )( T );
    3531 forall( type T, type U ) U ( *fTpfU( T ) )( U );
    3532 \end{lstlisting}
    3533 \lstinline$fTpfi()$ is a polymorphic function that returns a pointer to a monomorphic function
    3534 taking an integer and returning an integer. It could return \lstinline$pfi$. \lstinline$fTpfT()$
    3535 is subtle: it is a polymorphic function returning a \emph{monomorphic} function taking and returning
    3536 \lstinline$T$, where \lstinline$T$ is an inferred parameter of \lstinline$fTpfT()$. For instance,
    3537 in the expression ``\lstinline$fTpfT(17)$'', \lstinline$T$ is inferred to be \lstinline$int$, and
    3538 the returned value would have type \lstinline$int ( * )( int )$. ``\lstinline$fTpfT(17)(13)$'' and
     2934\lstinline$fvpfi()$ and \lstinline$fvpfT()$ are functions taking no arguments and returning pointers to functions. \lstinline$fvpfT()$ is monomorphic, but the function that its return value points at is polymorphic.
     2935\begin{lstlisting}
     2936forall( otype T ) int ( *fTpfi( T ) )( int );
     2937forall( otype T ) T ( *fTpfT( T ) )( T );
     2938forall( otype T, otype U ) U ( *fTpfU( T ) )( U );
     2939\end{lstlisting}
     2940\lstinline$fTpfi()$ is a polymorphic function that returns a pointer to a monomorphic function taking an integer and returning an integer.
     2941It could return \lstinline$pfi$. \lstinline$fTpfT()$ is subtle: it is a polymorphic function returning a \emph{monomorphic} function taking and returning
     2942\lstinline$T$, where \lstinline$T$ is an inferred parameter of \lstinline$fTpfT()$.
     2943For instance, in the expression ``\lstinline$fTpfT(17)$'', \lstinline$T$ is inferred to be \lstinline$int$, and the returned value would have type \lstinline$int ( * )( int )$. ``\lstinline$fTpfT(17)(13)$'' and
    35392944``\lstinline$fTpfT("yes")("no")$'' are legal, but ``\lstinline$fTpfT(17)("no")$'' is illegal.
    3540 \lstinline$fTpfU()$ is polymorphic ( in type \lstinline$T$), and returns a pointer to a function that
    3541 is polymorphic ( in type \lstinline$U$). ``\lstinline$f5(17)("no")$'' is a legal expression of type
     2945\lstinline$fTpfU()$ is polymorphic ( in type \lstinline$T$), and returns a pointer to a function that is polymorphic ( in type \lstinline$U$). ``\lstinline$f5(17)("no")$'' is a legal expression of type
    35422946\lstinline$char *$.
    35432947\begin{lstlisting}
    3544 forall( type T, type U, type V ) U * f( T *, U, V * const );
    3545 forall( type U, type V, type W ) U * g( V *, U, W * const );
    3546 \end{lstlisting}
    3547 The functions \lstinline$f()$ and \lstinline$g()$ have compatible types. Let \(f\) and \(g\) be
    3548 their types; then \(f_1\) = \lstinline$T$, \(f_2\) = \lstinline$U$, \(f_3\) = \lstinline$V$, \(g_1\)
    3549 = \lstinline$V$, \(g_2\) = \lstinline$U$, and \(g_3\) = \lstinline$W$. Replacing every \(f_i\)
    3550 by \(g_i\) in \(f\) gives
    3551 \begin{lstlisting}
    3552 forall( type V, type U, type W ) U * f( V *, U, W * const );
    3553 \end{lstlisting}
    3554 which has a return type and parameter list that is compatible with \(g\).
    3555 \begin{rationale}
    3556 The word ``\lstinline$type$'' in a forall specifier is redundant at the moment, but I want to leave
    3557 room for inferred parameters of ordinary types in case parameterized types get added one day.
     2948forall( otype T, otype U, otype V ) U * f( T *, U, V * const );
     2949forall( otype U, otype V, otype W ) U * g( V *, U, W * const );
     2950\end{lstlisting}
     2951The functions \lstinline$f()$ and \lstinline$g()$ have compatible types.
     2952Let \(f\) and \(g\) be their types;
     2953then \(f_1\) = \lstinline$T$, \(f_2\) = \lstinline$U$, \(f_3\) = \lstinline$V$, \(g_1\)
     2954= \lstinline$V$, \(g_2\) = \lstinline$U$, and \(g_3\) = \lstinline$W$.
     2955Replacing every \(f_i\) by \(g_i\) in \(f\) gives
     2956\begin{lstlisting}
     2957forall( otype V, otype U, otype W ) U * f( V *, U, W * const );
     2958\end{lstlisting} which has a return type and parameter list that is compatible with \(g\).
     2959\begin{rationale}
     2960The word ``\lstinline$type$'' in a forall specifier is redundant at the moment, but I want to leave room for inferred parameters of ordinary types in case parameterized types get added one day.
    35582961
    35592962Even without parameterized types, I might try to allow
    35602963\begin{lstlisting}
    35612964forall( int n ) int sum( int vector[n] );
    3562 \end{lstlisting}
    3563 but C currently rewrites array parameters as pointer parameters, so the effects of such a change
    3564 require more thought.
    3565 \end{rationale}
    3566 
    3567 \begin{rationale}
    3568 A polymorphic declaration must do two things: it must introduce type parameters, and it must apply
    3569 assertions to those types. Adding this to existing C declaration syntax and semantics was delicate,
    3570 and not entirely successful.
    3571 
    3572 C depends on declaration-before-use, so a forall specifier must introduce type names before they can
    3573 be used in the declaration specifiers. This could be done by making the forall specifier part of
    3574 the declaration specifiers, or by making it a new introductory clause of declarations.
    3575 
    3576 Assertions are also part of polymorphic function types, because it must be clear which functions
    3577 have access to the assertion parameters declared by the assertions. All attempts to put assertions
    3578 inside an introductory clause produced complex semantics and confusing code. Building them into the
    3579 declaration specifiers could be done by placing them in the function's parameter list, or in a
    3580 forall specifier that is a declaration specifier. Assertions are also used with type parameters of
    3581 specifications, and by type declarations. For consistency's sake it seems best to attach assertions
    3582 to the type declarations in forall specifiers, which means that forall specifiers must be
    3583 declaration specifiers.
     2965\end{lstlisting} but C currently rewrites array parameters as pointer parameters, so the effects of such a change require more thought.
     2966\end{rationale}
     2967
     2968\begin{rationale}
     2969A polymorphic declaration must do two things: it must introduce type parameters, and it must apply assertions to those types.
     2970Adding this to existing C declaration syntax and semantics was delicate, and not entirely successful.
     2971
     2972C depends on declaration-before-use, so a forall specifier must introduce type names before they can be used in the declaration specifiers.
     2973This could be done by making the forall specifier part of the declaration specifiers, or by making it a new introductory clause of declarations.
     2974
     2975Assertions are also part of polymorphic function types, because it must be clear which functions have access to the assertion parameters declared by the assertions.
     2976All attempts to put assertions inside an introductory clause produced complex semantics and confusing code.
     2977Building them into the declaration specifiers could be done by placing them in the function's parameter list, or in a forall specifier that is a declaration specifier.
     2978Assertions are also used with type parameters of specifications, and by type declarations.
     2979For consistency's sake it seems best to attach assertions to the type declarations in forall specifiers, which means that forall specifiers must be declaration specifiers.
    35842980\end{rationale}
    35852981%HERE
    … …  
    35952991
    35962992\constraints
    3597 \lstinline$restrict$\index{register@{\lstinline$restrict$}} Types other than type parameters and
    3598 pointer types whose referenced type is an object type shall not be restrict-qualified.
     2993\lstinline$restrict$\index{register@{\lstinline$restrict$}} Types other than type parameters and pointer types whose referenced type is an object type shall not be restrict-qualified.
    35992994
    36002995\semantics
    3601 An object's type may be a restrict-qualified type parameter. \lstinline$restrict$ does not
    3602 establish any special semantics in that case.
    3603 
    3604 \begin{rationale}
    3605 \CFA loosens the constraint on the restrict qualifier so that restrict-qualified pointers may be
    3606 passed to polymorphic functions.
    3607 \end{rationale}
    3608 
    3609 \lstinline$lvalue$ may be used to qualify the return type of a function type. Let \lstinline$T$ be
    3610 an unqualified version of a type; then the result of calling a function with return type
     2996An object's type may be a restrict-qualified type parameter. \lstinline$restrict$ does not establish any special semantics in that case.
     2997
     2998\begin{rationale}
     2999\CFA loosens the constraint on the restrict qualifier so that restrict-qualified pointers may be passed to polymorphic functions.
     3000\end{rationale}
     3001
     3002\lstinline$lvalue$ may be used to qualify the return type of a function type.
     3003Let \lstinline$T$ be an unqualified version of a type;
     3004then the result of calling a function with return type
    36113005\lstinline$lvalue T$ is a \Index{modifiable lvalue} of type \lstinline$T$.
    3612 \lstinline$const$\use{const} and \lstinline$volatile$\use{volatile} qualifiers may also be added to
    3613 indicate that the function result is a constant or volatile lvalue.
    3614 \begin{rationale}
    3615 The \lstinline$const$ and \lstinline$volatile$ qualifiers can only be sensibly used to qualify the
    3616 return type of a function if the \lstinline$lvalue$ qualifier is also used.
    3617 \end{rationale}
    3618 
    3619 An {lvalue}-qualified type may be used in a \Index{cast expression} if the operand is an lvalue; the
    3620 result of the expression is an lvalue.
    3621 
    3622 \begin{rationale}
    3623 \lstinline$lvalue$ provides some of the functionality of {\CC}'s ``\lstinline$T&$'' ( reference to
    3624 object of type \lstinline$T$) type. Reference types have four uses in {\CC}.
     3006\lstinline$const$\use{const} and \lstinline$volatile$\use{volatile} qualifiers may also be added to indicate that the function result is a constant or volatile lvalue.
     3007\begin{rationale}
     3008The \lstinline$const$ and \lstinline$volatile$ qualifiers can only be sensibly used to qualify the return type of a function if the \lstinline$lvalue$ qualifier is also used.
     3009\end{rationale}
     3010
     3011An {lvalue}-qualified type may be used in a \Index{cast expression} if the operand is an lvalue;
     3012the result of the expression is an lvalue.
     3013
     3014\begin{rationale}
     3015\lstinline$lvalue$ provides some of the functionality of {\CC}'s ``\lstinline$T&$'' ( reference to object of type \lstinline$T$) type.
     3016Reference types have four uses in {\CC}.
    36253017\begin{itemize}
    36263018\item
    … …  
    36293021
    36303022\item
    3631 A reference can be used to define an alias for a complicated lvalue expression, as a way of getting
    3632 some of the functionality of the Pascal \lstinline$with$ statement. The following {\CC} code gives
    3633 an example.
     3023A reference can be used to define an alias for a complicated lvalue expression, as a way of getting some of the functionality of the Pascal \lstinline$with$ statement.
     3024The following {\CC} code gives an example.
    36343025\begin{lstlisting}
    36353026{
    … …  
    36413032
    36423033\item
    3643 A reference parameter can be used to allow a function to modify an argument without forcing the
    3644 caller to pass the address of the argument. This is most useful for user-defined assignment
    3645 operators. In {\CC}, plain assignment is done by a function called ``\lstinline$operator=$'', and
    3646 the two expressions
     3034A reference parameter can be used to allow a function to modify an argument without forcing the caller to pass the address of the argument.
     3035This is most useful for user-defined assignment operators.
     3036In {\CC}, plain assignment is done by a function called ``\lstinline$operator=$'', and the two expressions
    36473037\begin{lstlisting}
    36483038a = b;
    36493039operator=( a, b );
    3650 \end{lstlisting}
    3651 are equivalent. If \lstinline$a$ and \lstinline$b$ are of type \lstinline$T$, then the first
    3652 parameter of \lstinline$operator=$ must have type ``\lstinline$T&$''. It cannot have type
     3040\end{lstlisting} are equivalent.
     3041If \lstinline$a$ and \lstinline$b$ are of type \lstinline$T$, then the first parameter of \lstinline$operator=$ must have type ``\lstinline$T&$''.
     3042It cannot have type
    36533043\lstinline$T$, because then assignment couldn't alter the variable, and it can't have type
    36543044``\lstinline$T *$'', because the assignment would have to be written ``\lstinline$&a = b;$''.
    36553045
    3656 In the case of user-defined operators, this could just as well be handled by using pointer types and
    3657 by changing the rewrite rules so that ``\lstinline$a = b;$'' is equivalent to
    3658 ``\lstinline$operator=(&( a), b )$''. Reference parameters of ``normal'' functions are Bad Things,
    3659 because they remove a useful property of C function calls: an argument can only be modified by a
    3660 function if it is preceded by ``\lstinline$&$''.
     3046In the case of user-defined operators, this could just as well be handled by using pointer types and by changing the rewrite rules so that ``\lstinline$a = b;$'' is equivalent to
     3047``\lstinline$operator=(&( a), b )$''.
     3048Reference parameters of ``normal'' functions are Bad Things, because they remove a useful property of C function calls: an argument can only be modified by a function if it is preceded by ``\lstinline$&$''.
    36613049
    36623050\item
    … …  
    36683056void fiddle( const Thing & );
    36693057\end{lstlisting}
    3670 If the second form is used, then constructors and destructors are not invoked to create a temporary
    3671 variable at the call site ( and it is bad style for the caller to make any assumptions about such
    3672 things), and within \lstinline$fiddle$ the parameter is subject to the usual problems caused by
    3673 aliases. The reference form might be chosen for efficiency's sake if \lstinline$Thing$s are too
    3674 large or their constructors or destructors are too expensive. An implementation may switch between
    3675 them without causing trouble for well-behaved clients. This leaves the implementor to define ``too
    3676 large'' and ``too expensive''.
     3058If the second form is used, then constructors and destructors are not invoked to create a temporary variable at the call site ( and it is bad style for the caller to make any assumptions about such things), and within \lstinline$fiddle$ the parameter is subject to the usual problems caused by aliases.
     3059The reference form might be chosen for efficiency's sake if \lstinline$Thing$s are too large or their constructors or destructors are too expensive.
     3060An implementation may switch between them without causing trouble for well-behaved clients.
     3061This leaves the implementor to define ``too large'' and ``too expensive''.
    36773062
    36783063I propose to push this job onto the compiler by allowing it to implement
    36793064\begin{lstlisting}
    36803065void fiddle( const volatile Thing );
    3681 \end{lstlisting}
    3682 with call-by-reference. Since it knows all about the size of \lstinline$Thing$s and the parameter
    3683 passing mechanism, it should be able to come up with a better definition of ``too large'', and may
    3684 be able to make a good guess at ``too expensive''.
     3066\end{lstlisting} with call-by-reference.
     3067Since it knows all about the size of \lstinline$Thing$s and the parameter passing mechanism, it should be able to come up with a better definition of ``too large'', and may be able to make a good guess at ``too expensive''.
    36853068\end{itemize}
    36863069
    3687 In summary, since references are only really necessary for returning lvalues, I'll only provide
    3688 lvalue functions.
     3070In summary, since references are only really necessary for returning lvalues, I'll only provide lvalue functions.
    36893071\end{rationale}
    36903072
    … …  
    36933075\subsection{Initialization}
    36943076
    3695 An expression that is used as an \nonterm{initializer} is treated as being cast to the type of the
    3696 object being initialized. An expression used in an \nonterm{initializer-list} is treated as being
    3697 cast to the type of the aggregate member that it initializes. In either case the cast must have a
    3698 single unambiguous \Index{interpretation}.
     3077An expression that is used as an \nonterm{initializer} is treated as being cast to the type of the object being initialized.
     3078An expression used in an \nonterm{initializer-list} is treated as being cast to the type of the aggregate member that it initializes.
     3079In either case the cast must have a single unambiguous \Index{interpretation}.
    36993080
    37003081
    … …  
    37173098\end{syntax}
    37183099\begin{rationale}
    3719 The declarations allowed in a specification are much the same as those allowed in a structure,
    3720 except that bit fields are not allowed, and \Index{incomplete type}s and function types are allowed.
     3100The declarations allowed in a specification are much the same as those allowed in a structure, except that bit fields are not allowed, and \Index{incomplete type}s and function types are allowed.
    37213101\end{rationale}
    37223102
    37233103\semantics
    3724 A \define{specification definition} defines a name for a \define{specification}: a parameterized
    3725 collection of object and function declarations.
     3104A \define{specification definition} defines a name for a \define{specification}: a parameterized collection of object and function declarations.
    37263105
    37273106The declarations in a specification consist of the declarations in the
    37283107\nonterm{spec-declaration-list} and declarations produced by any assertions in the
    3729 \nonterm{spec-parameter-list}. If the collection contains two declarations that declare the same
    3730 identifier and have compatible types, they are combined into one declaration with the composite type
    3731 constructed from the two types.
     3108\nonterm{spec-parameter-list}.
     3109If the collection contains two declarations that declare the same identifier and have compatible types, they are combined into one declaration with the composite type constructed from the two types.
    37323110
    37333111
    … …  
    37473125
    37483126\constraints
    3749 The \nonterm{identifier} in an assertion that is not a \nonterm{spec-declaration} shall be the name
    3750 of a specification. The \nonterm{type-name-list} shall contain one \nonterm{type-name} argument for
    3751 each \nonterm{type-parameter} in that specification's \nonterm{spec-parameter-list}. If the
    3752 \nonterm{type-parameter} uses type-class \lstinline$type$\use{type}, the argument shall be the type
    3753 name of an \Index{object type}; if it uses \lstinline$dtype$, the argument shall be the type name of
    3754 an object type or an \Index{incomplete type}; and if it uses \lstinline$ftype$, the argument shall
    3755 be the type name of a \Index{function type}.
     3127The \nonterm{identifier} in an assertion that is not a \nonterm{spec-declaration} shall be the name of a specification.
     3128The \nonterm{type-name-list} shall contain one \nonterm{type-name} argument for each \nonterm{type-parameter} in that specification's \nonterm{spec-parameter-list}.
     3129If the
     3130\nonterm{type-parameter} uses type-class \lstinline$type$\use{type}, the argument shall be the type name of an \Index{object type};
     3131if it uses \lstinline$dtype$, the argument shall be the type name of an object type or an \Index{incomplete type};
     3132and if it uses \lstinline$ftype$, the argument shall be the type name of a \Index{function type}.
    37563133
    37573134\semantics
    … …  
    37593136\define{assertion parameters}.
    37603137
    3761 The assertion parameters produced by an assertion that applies the name of a specification to type
    3762 arguments are found by taking the declarations specified in the specification and treating each of
    3763 the specification's parameters as a synonym for the corresponding \nonterm{type-name} argument.
    3764 
    3765 The collection of assertion parameters produced by the \nonterm{assertion-list} are found by
    3766 combining the declarations produced by each assertion. If the collection contains two declarations
    3767 that declare the same identifier and have compatible types, they are combined into one declaration
    3768 with the \Index{composite type} constructed from the two types.
     3138The assertion parameters produced by an assertion that applies the name of a specification to type arguments are found by taking the declarations specified in the specification and treating each of the specification's parameters as a synonym for the corresponding \nonterm{type-name} argument.
     3139
     3140The collection of assertion parameters produced by the \nonterm{assertion-list} are found by combining the declarations produced by each assertion.
     3141If the collection contains two declarations that declare the same identifier and have compatible types, they are combined into one declaration with the \Index{composite type} constructed from the two types.
    37693142
    37703143\examples
    37713144\begin{lstlisting}
    3772 forall( type T | T ?*?( T, T ))@\use{?*?}@
     3145forall( otype T | T ?*?( T, T ))@\use{?*?}@
    37733146T square( T val ) {@\impl{square}@
    37743147        return val + val;
    37753148}
    3776 
    3777 context summable( type T ) {@\impl{summable}@
     3149trait summable( otype T ) {@\impl{summable}@
    37783150        T ?+=?( T *, T );@\use{?+=?}@
    37793151        const T 0;@\use{0}@
    37803152};
    3781 context list_of( type List, type Element ) {@\impl{list_of}@
     3153trait list_of( otype List, otype Element ) {@\impl{list_of}@
    37823154        Element car( List );
    37833155        List cdr( List );
    … …  
    37863158        int is_nil( List );
    37873159};
    3788 context sum_list( type List, type Element | summable( Element ) | list_of( List, Element ) ) {};
    3789 \end{lstlisting}
    3790 \lstinline$sum_list$ contains seven declarations, which describe a list whose elements can be added
    3791 up. The assertion ``\lstinline$|sum_list( i_list, int )$''\use{sum_list} produces the assertion
    3792 parameters
     3160trait sum_list( otype List, otype Element | summable( Element ) | list_of( List, Element ) ) {};
     3161\end{lstlisting}
     3162\lstinline$sum_list$ contains seven declarations, which describe a list whose elements can be added up.
     3163The assertion ``\lstinline$|sum_list( i_list, int )$''\use{sum_list} produces the assertion parameters
    37933164\begin{lstlisting}
    37943165int ?+=?( int *, int );
    … …  
    38253196
    38263197\constraints
    3827 If a type declaration has block scope, and the declared identifier has external or internal linkage,
    3828 the declaration shall have no initializer for the identifier.
     3198If a type declaration has block scope, and the declared identifier has external or internal linkage, the declaration shall have no initializer for the identifier.
    38293199
    38303200\semantics
    3831 A \nonterm{type-parameter} or a \nonterm{type-declarator} declares an identifier to be a \Index{type
    3832 name} for a type incompatible with all other types.
    3833 
    3834 An identifier declared by a \nonterm{type-parameter} has \Index{no linkage}. Identifiers declared
    3835 with type-class \lstinline$type$\use{type} are \Index{object type}s; those declared with type-class
    3836 \lstinline$dtype$\use{dtype} are \Index{incomplete type}s; and those declared with type-class
    3837 \lstinline$ftype$\use{ftype} are \Index{function type}s. The identifier has \Index{block scope} that
    3838 terminates at the end of the \nonterm{spec-declaration-list} or polymorphic function that contains
    3839 the \nonterm{type-parameter}.
    3840 
    3841 A \nonterm{type-declarator} with an \Index{initializer} is a \define{type definition}.  The declared
    3842 identifier is an \Index{incomplete type} within the initializer, and an \Index{object type} after
    3843 the end of the initializer. The type in the initializer is called the \define{implementation
    3844   type}. Within the scope of the declaration, \Index{implicit conversion}s can be performed between
    3845 the defined type and the implementation type, and between pointers to the defined type and pointers
    3846 to the implementation type.
    3847 
    3848 A type declaration without an \Index{initializer} and without a \Index{storage-class specifier} or
    3849 with storage-class specifier \lstinline$static$\use{static} defines an \Index{incomplete type}. If a
    3850 \Index{translation unit} or \Index{block} contains one or more such declarations for an identifier,
    3851 it must contain exactly one definition of the identifier ( but not in an enclosed block, which would
    3852 define a new type known only within that block).
     3201A \nonterm{type-parameter} or a \nonterm{type-declarator} declares an identifier to be a \Index{type name} for a type incompatible with all other types.
     3202
     3203An identifier declared by a \nonterm{type-parameter} has \Index{no linkage}.
     3204Identifiers declared with type-class \lstinline$type$\use{type} are \Index{object type}s;
     3205those declared with type-class
     3206\lstinline$dtype$\use{dtype} are \Index{incomplete type}s;
     3207and those declared with type-class
     3208\lstinline$ftype$\use{ftype} are \Index{function type}s.
     3209The identifier has \Index{block scope} that terminates at the end of the \nonterm{spec-declaration-list} or polymorphic function that contains the \nonterm{type-parameter}.
     3210
     3211A \nonterm{type-declarator} with an \Index{initializer} is a \define{type definition}.  The declared identifier is an \Index{incomplete type} within the initializer, and an \Index{object type} after the end of the initializer.
     3212The type in the initializer is called the \define{implementation
     3213  type}.
     3214Within the scope of the declaration, \Index{implicit conversion}s can be performed between the defined type and the implementation type, and between pointers to the defined type and pointers to the implementation type.
     3215
     3216A type declaration without an \Index{initializer} and without a \Index{storage-class specifier} or with storage-class specifier \lstinline$static$\use{static} defines an \Index{incomplete type}.
     3217If a
     3218\Index{translation unit} or \Index{block} contains one or more such declarations for an identifier, it must contain exactly one definition of the identifier ( but not in an enclosed block, which would define a new type known only within that block).
    38533219\begin{rationale}
    38543220Incomplete type declarations allow compact mutually-recursive types.
    38553221\begin{lstlisting}
    3856 type t1; // Incomplete type declaration.
    3857 type t2 = struct { t1 * p; ... };
    3858 type t1 = struct { t2 * p; ... };
    3859 \end{lstlisting}
    3860 Without them, mutual recursion could be handled by declaring mutually recursive structures, then
    3861 initializing the types to those structures.
     3222otype t1; // incomplete type declaration
     3223otype t2 = struct { t1 * p; ... };
     3224otype t1 = struct { t2 * p; ... };
     3225\end{lstlisting}
     3226Without them, mutual recursion could be handled by declaring mutually recursive structures, then initializing the types to those structures.
    38623227\begin{lstlisting}
    38633228struct s1;
    3864 type t2 = struct s2 { struct s1 * p; ... };
    3865 type t1 = struct s1 { struct s2 * p; ... };
    3866 \end{lstlisting}
    3867 This introduces extra names, and may force the programmer to cast between the types and their
    3868 implementations.
     3229otype t2 = struct s2 { struct s1 * p; ... };
     3230otype t1 = struct s1 { struct s2 * p; ... };
     3231\end{lstlisting}
     3232This introduces extra names, and may force the programmer to cast between the types and their implementations.
    38693233\end{rationale}
    38703234
    38713235A type declaration without an initializer and with \Index{storage-class specifier}
    3872 \lstinline$extern$\use{extern} is an \define{opaque type declaration}. Opaque types are
    3873 \Index{object type}s. An opaque type is not a \nonterm{constant-expression}; neither is a structure
    3874 or union that has a member whose type is not a \nonterm{constant-expression}.  Every other
    3875 \Index{object type} is a \nonterm{constant-expression}. Objects with static storage duration shall
    3876 be declared with a type that is a \nonterm{constant-expression}.
    3877 \begin{rationale}
    3878 Type declarations can declare identifiers with external linkage, whereas typedef declarations
    3879 declare identifiers that only exist within a translation unit. These opaque types can be used in
    3880 declarations, but the implementation of the type is not visible.
    3881 
    3882 Static objects can not have opaque types because space for them would have to be allocated at
    3883 program start-up. This is a deficiency\index{deficiencies!static opaque objects}, but I don't want
    3884 to deal with ``module initialization'' code just now.
    3885 \end{rationale}
    3886 
    3887 An \Index{incomplete type} which is not a qualified version\index{qualified type} of a type is a
    3888 value of \Index{type-class} \lstinline$dtype$. An object type\index{object types} which is not a
    3889 qualified version of a type is a value of type-classes \lstinline$type$ and \lstinline$dtype$. A
     3236\lstinline$extern$\use{extern} is an \define{opaque type declaration}.
     3237Opaque types are
     3238\Index{object type}s.
     3239An opaque type is not a \nonterm{constant-expression};
     3240neither is a structure or union that has a member whose type is not a \nonterm{constant-expression}.  Every other
     3241\Index{object type} is a \nonterm{constant-expression}.
     3242Objects with static storage duration shall be declared with a type that is a \nonterm{constant-expression}.
     3243\begin{rationale}
     3244Type declarations can declare identifiers with external linkage, whereas typedef declarations declare identifiers that only exist within a translation unit.
     3245These opaque types can be used in declarations, but the implementation of the type is not visible.
     3246
     3247Static objects can not have opaque types because space for them would have to be allocated at program start-up.
     3248This is a deficiency\index{deficiencies!static opaque objects}, but I don't want to deal with ``module initialization'' code just now.
     3249\end{rationale}
     3250
     3251An \Index{incomplete type} which is not a qualified version\index{qualified type} of a type is a value of \Index{type-class} \lstinline$dtype$.
     3252An object type\index{object types} which is not a qualified version of a type is a value of type-classes \lstinline$type$ and \lstinline$dtype$.
     3253A
    38903254\Index{function type} is a value of type-class \lstinline$ftype$.
    38913255\begin{rationale}
    3892 Syntactically, a type value is a \nonterm{type-name}, which is a declaration for an object which
    3893 omits the identifier being declared.
    3894 
    3895 Object types are precisely the types that can be instantiated. Type qualifiers are not included in
    3896 type values because the compiler needs the information they provide at compile time to detect
    3897 illegal statements or to produce efficient machine instructions. For instance, the code that a
    3898 compiler must generate to manipulate an object that has volatile-qualified type may be different
    3899 from the code to manipulate an ordinary object.
    3900 
    3901 Type qualifiers are a weak point of C's type system. Consider the standard library function
    3902 \lstinline$strchr()$ which, given a string and a character, returns a pointer to the first
    3903 occurrence of the character in the string.
     3256Syntactically, a type value is a \nonterm{type-name}, which is a declaration for an object which omits the identifier being declared.
     3257
     3258Object types are precisely the types that can be instantiated.
     3259Type qualifiers are not included in type values because the compiler needs the information they provide at compile time to detect illegal statements or to produce efficient machine instructions.
     3260For instance, the code that a compiler must generate to manipulate an object that has volatile-qualified type may be different from the code to manipulate an ordinary object.
     3261
     3262Type qualifiers are a weak point of C's type system.
     3263Consider the standard library function
     3264\lstinline$strchr()$ which, given a string and a character, returns a pointer to the first occurrence of the character in the string.
    39043265\begin{lstlisting}
    39053266char *strchr( const char *s, int c ) {@\impl{strchr}@
    39063267        char real_c = c; // done because c was declared as int.
    39073268        for ( ; *s != real_c; s++ )
    3908          if ( *s == '\0' ) return NULL;
     3269                if ( *s == '\0' ) return NULL;
    39093270        return ( char * )s;
    39103271}
    39113272\end{lstlisting}
    3912 The parameter \lstinline$s$ must be \lstinline$const char *$, because \lstinline$strchr()$ might be
    3913 used to search a constant string, but the return type must be \lstinline$char *$, because the result
    3914 might be used to modify a non-constant string. Hence the body must perform a cast, and ( even worse)
    3915 \lstinline$strchr()$ provides a type-safe way to attempt to modify constant strings. What is needed
    3916 is some way to say that \lstinline$s$'s type might contain qualifiers, and the result type has
    3917 exactly the same qualifiers. Polymorphic functions do not provide a fix for this
    3918 deficiency\index{deficiencies!pointers to qualified types}, because type qualifiers are not part of
    3919 type values. Instead, overloading can be used to define \lstinline$strchr()$ for each combination
    3920 of qualifiers.
    3921 \end{rationale}
    3922 
    3923 \begin{rationale}
    3924 Since \Index{incomplete type}s are not type values, they can not be used as the initializer in a
    3925 type declaration, or as the type of a structure or union member. This prevents the declaration of
    3926 types that contain each other.
    3927 \begin{lstlisting}
    3928 type t1;
    3929 type t2 = t1; // illegal: incomplete type t1.
    3930 type t1 = t2;
    3931 \end{lstlisting}
    3932 
    3933 The initializer in a file-scope declaration must be a constant expression. This means type
    3934 declarations can not build on opaque types, which is a deficiency\index{deficiencies!nesting opaque
     3273The parameter \lstinline$s$ must be \lstinline$const char *$, because \lstinline$strchr()$ might be used to search a constant string, but the return type must be \lstinline$char *$, because the result might be used to modify a non-constant string.
     3274Hence the body must perform a cast, and ( even worse)
     3275\lstinline$strchr()$ provides a type-safe way to attempt to modify constant strings.
     3276What is needed is some way to say that \lstinline$s$'s type might contain qualifiers, and the result type has exactly the same qualifiers.
     3277Polymorphic functions do not provide a fix for this deficiency\index{deficiencies!pointers to qualified types}, because type qualifiers are not part of type values.
     3278Instead, overloading can be used to define \lstinline$strchr()$ for each combination of qualifiers.
     3279\end{rationale}
     3280
     3281\begin{rationale}
     3282Since \Index{incomplete type}s are not type values, they can not be used as the initializer in a type declaration, or as the type of a structure or union member.
     3283This prevents the declaration of types that contain each other.
     3284\begin{lstlisting}
     3285otype t1;
     3286otype t2 = t1; // illegal: incomplete type t1
     3287otype t1 = t2;
     3288\end{lstlisting}
     3289
     3290The initializer in a file-scope declaration must be a constant expression.
     3291This means type declarations can not build on opaque types, which is a deficiency\index{deficiencies!nesting opaque
    39353292 types}.
    39363293\begin{lstlisting}
    3937 extern type Huge; // extended-precision integer type.
    3938 type Rational = struct {
     3294extern otype Huge; // extended-precision integer type
     3295otype Rational = struct {
    39393296        Huge numerator, denominator;    // illegal
    39403297};
    … …  
    39443301\end{lstlisting}
    39453302Without this restriction, \CFA might require ``module initialization'' code ( since
    3946 \lstinline$Rational$ has external linkage, it must be created before any other translation unit
    3947 instantiates it), and would force an ordering on the initialization of the translation unit that
    3948 defines \lstinline$Huge$ and the translation that declares \lstinline$Rational$.
    3949 
    3950 A benefit of the restriction is that it prevents the declaration in separate translation units of
    3951 types that contain each other, which would be hard to prevent otherwise.
     3303\lstinline$Rational$ has external linkage, it must be created before any other translation unit instantiates it), and would force an ordering on the initialization of the translation unit that defines \lstinline$Huge$ and the translation that declares \lstinline$Rational$.
     3304
     3305A benefit of the restriction is that it prevents the declaration in separate translation units of types that contain each other, which would be hard to prevent otherwise.
    39523306\begin{lstlisting}
    39533307//  File a.c:
    … …  
    39623316\begin{rationale}
    39633317Since a \nonterm{type-declaration} is a \nonterm{declaration} and not a
    3964 \nonterm{struct-declaration}, type declarations can not be structure members. The form of
     3318\nonterm{struct-declaration}, type declarations can not be structure members.
     3319The form of
    39653320\nonterm{type-declaration} forbids arrays of, pointers to, and functions returning \lstinline$type$.
    3966 Hence the syntax of \nonterm{type-specifier} does not have to be extended to allow type-valued
    3967 expressions. It also side-steps the problem of type-valued expressions producing different values
    3968 in different declarations.
    3969 
    3970 Since a type declaration is not a \nonterm{parameter-declaration}, functions can not have explicit
    3971 type parameters. This may be too restrictive, but it attempts to make compilation simpler. Recall
    3972 that when traditional C scanners read in an identifier, they look it up in the symbol table to
    3973 determine whether or not it is a typedef name, and return a ``type'' or ``identifier'' token
    3974 depending on what they find. A type parameter would add a type name to the current scope. The
    3975 scope manipulations involved in parsing the declaration of a function that takes function pointer
    3976 parameters and returns a function pointer may just be too complicated.
    3977 
    3978 Explicit type parameters don't seem to be very useful, anyway, because their scope would not include
    3979 the return type of the function. Consider the following attempt to define a type-safe memory
    3980 allocation function.
     3321Hence the syntax of \nonterm{type-specifier} does not have to be extended to allow type-valued expressions.
     3322It also side-steps the problem of type-valued expressions producing different values in different declarations.
     3323
     3324Since a type declaration is not a \nonterm{parameter-declaration}, functions can not have explicit type parameters.
     3325This may be too restrictive, but it attempts to make compilation simpler.
     3326Recall that when traditional C scanners read in an identifier, they look it up in the symbol table to determine whether or not it is a typedef name, and return a ``type'' or ``identifier'' token depending on what they find.
     3327A type parameter would add a type name to the current scope.
     3328The scope manipulations involved in parsing the declaration of a function that takes function pointer parameters and returns a function pointer may just be too complicated.
     3329
     3330Explicit type parameters don't seem to be very useful, anyway, because their scope would not include the return type of the function.
     3331Consider the following attempt to define a type-safe memory allocation function.
    39813332\begin{lstlisting}
    39823333#include <stdlib.h>
    3983 T * new( type T ) { return ( T * )malloc( sizeof( T) ); };
    3984 @\ldots@
    3985 int * ip = new( int );
    3986 \end{lstlisting}
    3987 This looks sensible, but \CFA's declaration-before-use rules mean that ``\lstinline$T$'' in the
    3988 function body refers to the parameter, but the ``\lstinline$T$'' in the return type refers to the
    3989 meaning of \lstinline$T$ in the scope that contains \lstinline$new$; it could be undefined, or a
    3990 type name, or a function or variable name. Nothing good can result from such a situation.
     3334T * new( otype T ) { return ( T * )malloc( sizeof( T) ); };
     3335@\ldots@ int * ip = new( int );
     3336\end{lstlisting}
     3337This looks sensible, but \CFA's declaration-before-use rules mean that ``\lstinline$T$'' in the function body refers to the parameter, but the ``\lstinline$T$'' in the return type refers to the meaning of \lstinline$T$ in the scope that contains \lstinline$new$;
     3338it could be undefined, or a type name, or a function or variable name.
     3339Nothing good can result from such a situation.
    39913340\end{rationale}
    39923341
    … …  
    39943343Since type declarations create new types, instances of types are always passed by value.
    39953344\begin{lstlisting}
    3996 type A1 = int[2];
     3345otype A1 = int[2];
    39973346void f1( A1 a ) { a[0] = 0; };
    3998 typedef int A2[2];
     3347otypedef int A2[2];
    39993348void f2( A2 a ) { a[0] = 0; };
    40003349A1 v1;
    … …  
    40033352f2( v2 );
    40043353\end{lstlisting}
    4005 \lstinline$V1$ is passed by value, so \lstinline$f1()$'s assignment to \lstinline$a[0]$ does not
    4006 modify v1.  \lstinline$V2$ is converted to a pointer, so \lstinline$f2()$ modifies
    4007 \lstinline$v2[0]$.
     3354\lstinline$V1$ is passed by value, so \lstinline$f1()$'s assignment to \lstinline$a[0]$ does not modify v1.  \lstinline$V2$ is converted to a pointer, so \lstinline$f2()$ modifies \lstinline$v2[0]$.
    40083355
    40093356A translation unit containing the declarations
    40103357\begin{lstlisting}
    4011 extern type Complex;@\use{Complex}@ // opaque type declaration.
     3358extern type Complex;@\use{Complex}@ // opaque type declaration
    40123359extern float abs( Complex );@\use{abs}@
    4013 \end{lstlisting}
    4014 can contain declarations of complex numbers, which can be passed to \lstinline$abs$. Some other
    4015 translation unit must implement \lstinline$Complex$ and \lstinline$abs$. That unit might contain
    4016 the declarations
    4017 \begin{lstlisting}
    4018 type Complex = struct { float re, im; };@\impl{Complex}@
     3360\end{lstlisting} can contain declarations of complex numbers, which can be passed to \lstinline$abs$.
     3361Some other translation unit must implement \lstinline$Complex$ and \lstinline$abs$.
     3362That unit might contain the declarations
     3363\begin{lstlisting}
     3364otype Complex = struct { float re, im; };@\impl{Complex}@
    40193365Complex cplx_i = { 0.0, 1.0 };@\impl{cplx_i}@
    40203366float abs( Complex c ) {@\impl{abs( Complex )}@
    … …  
    40223368}
    40233369\end{lstlisting}
    4024 Note that \lstinline$c$ is implicitly converted to a \lstinline$struct$ so that its components can
    4025 be retrieved.
    4026 
    4027 \begin{lstlisting}
    4028 type Time_of_day = int;@\impl{Time_of_day}@ // seconds since midnight.
     3370Note that \lstinline$c$ is implicitly converted to a \lstinline$struct$ so that its components can be retrieved.
     3371
     3372\begin{lstlisting}
     3373otype Time_of_day = int;@\impl{Time_of_day}@ // seconds since midnight.
    40293374Time_of_day ?+?( Time_of_day t1, int seconds ) {@\impl{?+?}@
    40303375        return (( int)t1 + seconds ) % 86400;
    … …  
    40343379
    40353380\begin{rationale}
    4036 Within the scope of a type definition, an instance of the type can be viewed as having that type or
    4037 as having the implementation type. In the \lstinline$Time_of_day$ example, the difference is
    4038 important. Different languages have treated the distinction between the abstraction and the
    4039 implementation in different ways.
     3381Within the scope of a type definition, an instance of the type can be viewed as having that type or as having the implementation type.
     3382In the \lstinline$Time_of_day$ example, the difference is important.
     3383Different languages have treated the distinction between the abstraction and the implementation in different ways.
    40403384\begin{itemize}
    40413385\item
    4042 Inside a Clu cluster \cite{clu}, the declaration of an instance states which view applies. Two
    4043 primitives called \lstinline$up$ and \lstinline$down$ can be used to convert between the views.
    4044 \item
    4045 The Simula class \cite{Simula87} is essentially a record type. Since the only operations on a
    4046 record are member selection and assignment, which can not be overloaded, there is never any
    4047 ambiguity as to whether the abstraction or the implementation view is being used. In {\CC}
    4048 \cite{c++}, operations on class instances include assignment and ``\lstinline$&$'', which can be
    4049 overloaded. A ``scope resolution'' operator can be used inside the class to specify whether the
    4050 abstract or implementation version of the operation should be used.
    4051 \item
    4052 An Ada derived type definition \cite{ada} creates a new type from an old type, and also implicitly
    4053 declares derived subprograms that correspond to the existing subprograms that use the old type as a
    4054 parameter type or result type. The derived subprograms are clones of the existing subprograms with
    4055 the old type replaced by the derived type. Literals and aggregates of the old type are also cloned.
     3386Inside a Clu cluster \cite{clu}, the declaration of an instance states which view applies.
     3387Two primitives called \lstinline$up$ and \lstinline$down$ can be used to convert between the views.
     3388\item
     3389The Simula class \cite{Simula87} is essentially a record type.
     3390Since the only operations on a record are member selection and assignment, which can not be overloaded, there is never any ambiguity as to whether the abstraction or the implementation view is being used.
     3391In {\CC}
     3392\cite{c++}, operations on class instances include assignment and ``\lstinline$&$'', which can be overloaded.
     3393A ``scope resolution'' operator can be used inside the class to specify whether the abstract or implementation version of the operation should be used.
     3394\item
     3395An Ada derived type definition \cite{ada} creates a new type from an old type, and also implicitly declares derived subprograms that correspond to the existing subprograms that use the old type as a parameter type or result type.
     3396The derived subprograms are clones of the existing subprograms with the old type replaced by the derived type.
     3397Literals and aggregates of the old type are also cloned.
    40563398In other words, the abstract view provides exactly the same operations as the implementation view.
    40573399This allows the abstract view to be used in all cases.
    40583400
    4059 The derived subprograms can be replaced by programmer-specified subprograms. This is an exception
    4060 to the normal scope rules, which forbid duplicate definitions of a subprogram in a scope. In this
    4061 case, explicit conversions between the derived type and the old type can be used.
     3401The derived subprograms can be replaced by programmer-specified subprograms.
     3402This is an exception to the normal scope rules, which forbid duplicate definitions of a subprogram in a scope.
     3403In this case, explicit conversions between the derived type and the old type can be used.
    40623404\end{itemize}
    4063 \CFA's rules are like Clu's, except that implicit conversions and
    4064 conversion costs allow it to do away with most uses of \lstinline$up$ and \lstinline$down$.
     3405\CFA's rules are like Clu's, except that implicit conversions and conversion costs allow it to do away with most uses of \lstinline$up$ and \lstinline$down$.
    40653406\end{rationale}
    40663407
    … …  
    40703411A declaration\index{type declaration} of a type identifier \lstinline$T$ with type-class
    40713412\lstinline$type$ implicitly declares a \define{default assignment} function
    4072 \lstinline$T ?=?( T *, T )$\use{?=?}, with the same \Index{scope} and \Index{linkage} as the
    4073 identifier \lstinline$T$.
    4074 \begin{rationale}
    4075 Assignment is central to C's imperative programming style, and every existing C object type has
    4076 assignment defined for it ( except for array types, which are treated as pointer types for purposes
    4077 of assignment). Without this rule, nearly every inferred type parameter would need an accompanying
    4078 assignment assertion parameter. If a type parameter should not have an assignment operation,
    4079 \lstinline$dtype$ should be used. If a type should not have assignment defined, the user can define
    4080 an assignment function that causes a run-time error, or provide an external declaration but no
    4081 definition and thus cause a link-time error.
    4082 \end{rationale}
    4083 
    4084 A definition\index{type definition} of a type identifier \lstinline$T$ with \Index{implementation
    4085 type} \lstinline$I$ and type-class \lstinline$type$ implicitly defines a default assignment
    4086 function. A definition\index{type definition} of a type identifier \lstinline$T$ with implementation
    4087 type \lstinline$I$ and an assertion list implicitly defines \define{default function}s and
    4088 \define{default object}s as declared by the assertion declarations. The default objects and
    4089 functions have the same \Index{scope} and \Index{linkage} as the identifier \lstinline$T$. Their
    4090 values are determined as follows:
     3413\lstinline$T ?=?( T *, T )$\use{?=?}, with the same \Index{scope} and \Index{linkage} as the identifier \lstinline$T$.
     3414\begin{rationale}
     3415Assignment is central to C's imperative programming style, and every existing C object type has assignment defined for it ( except for array types, which are treated as pointer types for purposes of assignment).
     3416Without this rule, nearly every inferred type parameter would need an accompanying assignment assertion parameter.
     3417If a type parameter should not have an assignment operation,
     3418\lstinline$dtype$ should be used.
     3419If a type should not have assignment defined, the user can define an assignment function that causes a run-time error, or provide an external declaration but no definition and thus cause a link-time error.
     3420\end{rationale}
     3421
     3422A definition\index{type definition} of a type identifier \lstinline$T$ with \Index{implementation type} \lstinline$I$ and type-class \lstinline$type$ implicitly defines a default assignment function.
     3423A definition\index{type definition} of a type identifier \lstinline$T$ with implementation type \lstinline$I$ and an assertion list implicitly defines \define{default function}s and
     3424\define{default object}s as declared by the assertion declarations.
     3425The default objects and functions have the same \Index{scope} and \Index{linkage} as the identifier \lstinline$T$.
     3426Their values are determined as follows:
    40913427\begin{itemize}
    40923428\item
    4093 If at the definition of \lstinline$T$ there is visible a declaration of an object with the same name
    4094 as the default object, and if the type of that object with all occurrence of \lstinline$I$ replaced
    4095 by \lstinline$T$ is compatible with the type of the default object, then the default object is
    4096 initialized with that object. Otherwise the scope of the declaration of \lstinline$T$ must contain
    4097 a definition of the default object.
     3429If at the definition of \lstinline$T$ there is visible a declaration of an object with the same name as the default object, and if the type of that object with all occurrence of \lstinline$I$ replaced by \lstinline$T$ is compatible with the type of the default object, then the default object is initialized with that object.
     3430Otherwise the scope of the declaration of \lstinline$T$ must contain a definition of the default object.
    40983431
    40993432\item
    4100 If at the definition of \lstinline$T$ there is visible a declaration of a function with the same
    4101 name as the default function, and if the type of that function with all occurrence of \lstinline$I$
    4102 replaced by \lstinline$T$ is compatible with the type of the default function, then the default
    4103 function calls that function after converting its arguments and returns the converted result.
    4104 
    4105 Otherwise, if \lstinline$I$ contains exactly one anonymous member\index{anonymous member} such that
    4106 at the definition of \lstinline$T$ there is visible a declaration of a function with the same name
    4107 as the default function, and the type of that function with all occurrences of the anonymous
    4108 member's type in its parameter list replaced by \lstinline$T$ is compatible with the type of the
    4109 default function, then the default function calls that function after converting its arguments and
    4110 returns the result.
    4111 
    4112 Otherwise the scope of the declaration of \lstinline$T$ must contain a definition of the default
    4113 function.
     3433If at the definition of \lstinline$T$ there is visible a declaration of a function with the same name as the default function, and if the type of that function with all occurrence of \lstinline$I$ replaced by \lstinline$T$ is compatible with the type of the default function, then the default function calls that function after converting its arguments and returns the converted result.
     3434
     3435Otherwise, if \lstinline$I$ contains exactly one anonymous member\index{anonymous member} such that at the definition of \lstinline$T$ there is visible a declaration of a function with the same name as the default function, and the type of that function with all occurrences of the anonymous member's type in its parameter list replaced by \lstinline$T$ is compatible with the type of the default function, then the default function calls that function after converting its arguments and returns the result.
     3436
     3437Otherwise the scope of the declaration of \lstinline$T$ must contain a definition of the default function.
    41143438\end{itemize}
    41153439\begin{rationale}
    4116 Note that a pointer to a default function will not compare as equal to a pointer to the inherited
    4117 function.
    4118 \end{rationale}
    4119 
    4120 A function or object with the same type and name as a default function or object that is declared
    4121 within the scope of the definition of \lstinline$T$ replaces the default function or object.
     3440Note that a pointer to a default function will not compare as equal to a pointer to the inherited function.
     3441\end{rationale}
     3442
     3443A function or object with the same type and name as a default function or object that is declared within the scope of the definition of \lstinline$T$ replaces the default function or object.
    41223444
    41233445\examples
    41243446\begin{lstlisting}
    4125 context s( type T ) {
     3447trait s( otype T ) {
    41263448        T a, b;
    4127 }
    4128 struct impl { int left, right; } a = { 0, 0 };
    4129 type Pair | s( Pair ) = struct impl;
     3449} struct impl { int left, right; } a = { 0, 0 };
     3450otype Pair | s( Pair ) = struct impl;
    41303451Pair b = { 1, 1 };
    41313452\end{lstlisting}
    41323453The definition of \lstinline$Pair$ implicitly defines two objects \lstinline$a$ and \lstinline$b$.
    4133 \lstinline$Pair a$ inherits its value from the \lstinline$struct impl a$. The definition of
    4134 \lstinline$Pair b$ is compulsory because there is no \lstinline$struct impl b$ to construct a value
    4135 from.
    4136 \begin{lstlisting}
    4137 context ss( type T ) {
     3454\lstinline$Pair a$ inherits its value from the \lstinline$struct impl a$.
     3455The definition of
     3456\lstinline$Pair b$ is compulsory because there is no \lstinline$struct impl b$ to construct a value from.
     3457\begin{lstlisting}
     3458trait ss( otype T ) {
    41383459        T clone( T );
    41393460        void munge( T * );
    41403461}
    4141 type Whatsit | ss( Whatsit );@\use{Whatsit}@
    4142 type Doodad | ss( Doodad ) = struct doodad {@\use{Doodad}@
     3462otype Whatsit | ss( Whatsit );@\use{Whatsit}@
     3463otype Doodad | ss( Doodad ) = struct doodad {@\use{Doodad}@
    41433464        Whatsit; // anonymous member
    41443465        int extra;
    … …  
    41523473void munge( Doodad * );
    41533474\end{lstlisting}
    4154 The assignment function inherits \lstinline$struct doodad$'s assignment function because the types
    4155 match when \lstinline$struct doodad$ is replaced by \lstinline$Doodad$ throughout.
     3475The assignment function inherits \lstinline$struct doodad$'s assignment function because the types match when \lstinline$struct doodad$ is replaced by \lstinline$Doodad$ throughout.
    41563476\lstinline$munge()$ inherits \lstinline$Whatsit$'s \lstinline$munge()$ because the types match when
    4157 \lstinline$Whatsit$ is replaced by \lstinline$Doodad$ in the parameter list. \lstinline$clone()$
    4158 does \emph{not} inherit \lstinline$Whatsit$'s \lstinline$clone()$: replacement in the parameter
    4159 list yields ``\lstinline$Whatsit clone( Doodad )$'', which is not compatible with
    4160 \lstinline$Doodad$'s \lstinline$clone()$'s type. Hence the definition of
     3477\lstinline$Whatsit$ is replaced by \lstinline$Doodad$ in the parameter list. \lstinline$clone()$ does \emph{not} inherit \lstinline$Whatsit$'s \lstinline$clone()$: replacement in the parameter list yields ``\lstinline$Whatsit clone( Doodad )$'', which is not compatible with
     3478\lstinline$Doodad$'s \lstinline$clone()$'s type.
     3479Hence the definition of
    41613480``\lstinline$Doodad clone( Doodad )$'' is necessary.
    41623481
    41633482Default functions and objects are subject to the normal scope rules.
    41643483\begin{lstlisting}
    4165 type T = @\ldots@;
     3484otype T = @\ldots@;
    41663485T a_T = @\ldots@;               // Default assignment used.
    41673486T ?=?( T *, T );
    … …  
    41733492
    41743493\begin{rationale}
    4175 The \emph{class} construct of object-oriented programming languages performs three independent
    4176 functions. It \emph{encapsulates} a data structure; it defines a \emph{subtype} relationship, whereby
    4177 instances of one class may be used in contexts that require instances of another; and it allows one
    4178 class to \emph{inherit} the implementation of another.
    4179 
    4180 In \CFA, encapsulation is provided by opaque types and the scope rules, and subtyping is provided
    4181 by specifications and assertions. Inheritance is provided by default functions and objects.
     3494The \emph{class} construct of object-oriented programming languages performs three independent functions.
     3495It \emph{encapsulates} a data structure;
     3496it defines a \emph{subtype} relationship, whereby instances of one class may be used in contexts that require instances of another;
     3497and it allows one class to \emph{inherit} the implementation of another.
     3498
     3499In \CFA, encapsulation is provided by opaque types and the scope rules, and subtyping is provided by specifications and assertions.
     3500Inheritance is provided by default functions and objects.
    41823501\end{rationale}
    41833502
    … …  
    41903509\end{syntax}
    41913510
    4192 Many statements contain expressions, which may have more than one interpretation. The following
    4193 sections describe how the \CFA translator selects an interpretation. In all cases the result of the
    4194 selection shall be a single unambiguous \Index{interpretation}.
     3511Many statements contain expressions, which may have more than one interpretation.
     3512The following sections describe how the \CFA translator selects an interpretation.
     3513In all cases the result of the selection shall be a single unambiguous \Index{interpretation}.
    41953514
    41963515
    … …  
    42393558switch ( E ) ...
    42403559choose ( E ) ...
    4241 \end{lstlisting}
    4242 may have more than one interpretation, but it shall have only one interpretation with an integral type.
     3560\end{lstlisting} may have more than one interpretation, but it shall have only one interpretation with an integral type.
    42433561An \Index{integer promotion} is performed on the expression if necessary.
    42443562The constant expressions in \lstinline$case$ statements with the switch are converted to the promoted type.
    … …  
    42843602while ( E ) ...
    42853603do ... while ( E );
    4286 \end{lstlisting}
    4287 is treated as ``\lstinline$( int )((E)!=0)$''.
     3604\end{lstlisting} is treated as ``\lstinline$( int )((E)!=0)$''.
    42883605
    42893606The statement
    42903607\begin{lstlisting}
    42913608for ( a; b; c ) @\ldots@
    4292 \end{lstlisting}
    4293 is treated as
     3609\end{lstlisting} is treated as
    42943610\begin{lstlisting}
    42953611for ( ( void )( a ); ( int )(( b )!=0); ( void )( c ) ) ...
    … …  
    44133729
    44143730The implementation shall define the macro names \lstinline$__LINE__$, \lstinline$__FILE__$,
    4415 \lstinline$__DATE__$, and \lstinline$__TIME__$, as in the {\c11} standard. It shall not define the
    4416 macro name \lstinline$__STDC__$.
    4417 
    4418 In addition, the implementation shall define the macro name \lstinline$__CFORALL__$ to be the
    4419 decimal constant 1.
     3731\lstinline$__DATE__$, and \lstinline$__TIME__$, as in the {\c11} standard.
     3732It shall not define the macro name \lstinline$__STDC__$.
     3733
     3734In addition, the implementation shall define the macro name \lstinline$__CFORALL__$ to be the decimal constant 1.
    44203735
    44213736
    … …  
    44273742
    44283743\section{C types}
    4429 This section gives example specifications for some groups of types that are important in the C
    4430 language, in terms of the predefined operations that can be applied to those types.
     3744This section gives example specifications for some groups of types that are important in the C language, in terms of the predefined operations that can be applied to those types.
    44313745
    44323746
    44333747\subsection{Scalar, arithmetic, and integral types}
    44343748
    4435 The pointer, integral, and floating-point types are all \define{scalar types}. All of these types
    4436 can be logically negated and compared. The assertion ``\lstinline$scalar( Complex )$'' should be read
    4437 as ``type \lstinline$Complex$ is scalar''.
    4438 \begin{lstlisting}
    4439 context scalar( type T ) {@\impl{scalar}@
     3749The pointer, integral, and floating-point types are all \define{scalar types}.
     3750All of these types can be logically negated and compared.
     3751The assertion ``\lstinline$scalar( Complex )$'' should be read as ``type \lstinline$Complex$ is scalar''.
     3752\begin{lstlisting}
     3753trait scalar( otype T ) {@\impl{scalar}@
    44403754        int !?( T );
    44413755        int ?<?( T, T ), ?<=?( T, T ), ?==?( T, T ), ?>=?( T, T ), ?>?( T, T ), ?!=?( T, T );
    … …  
    44433757\end{lstlisting}
    44443758
    4445 The integral and floating-point types are \define{arithmetic types}, which support the basic
    4446 arithmetic operators. The use of an assertion in the \nonterm{spec-parameter-list} declares that,
    4447 in order to be arithmetic, a type must also be scalar ( and hence that scalar operations are
    4448 available ). This is equivalent to inheritance of specifications.
    4449 \begin{lstlisting}
    4450 context arithmetic( type T | scalar( T ) ) {@\impl{arithmetic}@@\use{scalar}@
     3759The integral and floating-point types are \define{arithmetic types}, which support the basic arithmetic operators.
     3760The use of an assertion in the \nonterm{spec-parameter-list} declares that, in order to be arithmetic, a type must also be scalar ( and hence that scalar operations are available ).
     3761This is equivalent to inheritance of specifications.
     3762\begin{lstlisting}
     3763trait arithmetic( otype T | scalar( T ) ) {@\impl{arithmetic}@@\use{scalar}@
    44513764        T +?( T ), -?( T );
    44523765        T ?*?( T, T ), ?/?( T, T ), ?+?( T, T ), ?-?( T, T );
    … …  
    44573770\define{integral types}.
    44583771\begin{lstlisting}
    4459 context integral( type T | arithmetic( T ) ) {@\impl{integral}@@\use{arithmetic}@
     3772trait integral( otype T | arithmetic( T ) ) {@\impl{integral}@@\use{arithmetic}@
    44603773        T ~?( T );
    44613774        T ?&?( T, T ), ?|?( T, T ), ?^?( T, T );
    … …  
    44713784The only operation that can be applied to all modifiable lvalues is simple assignment.
    44723785\begin{lstlisting}
    4473 context m_lvalue( type T ) {@\impl{m_lvalue}@
     3786trait m_lvalue( otype T ) {@\impl{m_lvalue}@
    44743787        T ?=?( T *, T );
    44753788};
    … …  
    44773790
    44783791Modifiable scalar lvalues are scalars and are modifiable lvalues, and assertions in the
    4479 \nonterm{spec-parameter-list} reflect those relationships. This is equivalent to multiple
    4480 inheritance of specifications. Scalars can also be incremented and decremented.
    4481 \begin{lstlisting}
    4482 context m_l_scalar( type T | scalar( T ) | m_lvalue( T ) ) {@\impl{m_l_scalar}@
     3792\nonterm{spec-parameter-list} reflect those relationships.
     3793This is equivalent to multiple inheritance of specifications.
     3794Scalars can also be incremented and decremented.
     3795\begin{lstlisting}
     3796trait m_l_scalar( otype T | scalar( T ) | m_lvalue( T ) ) {@\impl{m_l_scalar}@
    44833797        T ?++( T * ), ?--( T * );@\use{scalar}@@\use{m_lvalue}@
    44843798        T ++?( T * ), --?( T * );
    … …  
    44863800\end{lstlisting}
    44873801
    4488 Modifiable arithmetic lvalues are both modifiable scalar lvalues and arithmetic. Note that this
    4489 results in the ``inheritance'' of \lstinline$scalar$ along both paths.
    4490 \begin{lstlisting}
    4491 context m_l_arithmetic( type T | m_l_scalar( T ) | arithmetic( T ) ) {@\impl{m_l_arithmetic}@
     3802Modifiable arithmetic lvalues are both modifiable scalar lvalues and arithmetic.
     3803Note that this results in the ``inheritance'' of \lstinline$scalar$ along both paths.
     3804\begin{lstlisting}
     3805trait m_l_arithmetic( otype T | m_l_scalar( T ) | arithmetic( T ) ) {@\impl{m_l_arithmetic}@
    44923806        T ?/=?( T *, T ), ?*=?( T *, T );@\use{m_l_scalar}@@\use{arithmetic}@
    44933807        T ?+=?( T *, T ), ?-=?( T *, T );
    44943808};
    4495 
    4496 context m_l_integral( type T | m_l_arithmetic( T ) | integral( T ) ) {@\impl{m_l_integral}@
     3809trait m_l_integral( otype T | m_l_arithmetic( T ) | integral( T ) ) {@\impl{m_l_integral}@
    44973810        T ?&=?( T *, T ), ?|=?( T *, T ), ?^=?( T *, T );@\use{m_l_arithmetic}@
    44983811        T ?%=?( T *, T ), ?<<=?( T *, T ), ?>>=?( T *, T );@\use{integral}@
    … …  
    45033816\subsection{Pointer and array types}
    45043817
    4505 Array types can barely be said to exist in {\c11}, since in most cases an array name is treated as a
    4506 constant pointer to the first element of the array, and the subscript expression
     3818Array types can barely be said to exist in {\c11}, since in most cases an array name is treated as a constant pointer to the first element of the array, and the subscript expression
    45073819``\lstinline$a[i]$'' is equivalent to the dereferencing expression ``\lstinline$(*( a+( i )))$''.
    45083820Technically, pointer arithmetic and pointer comparisons other than ``\lstinline$==$'' and
    4509 ``\lstinline$!=$'' are only defined for pointers to array elements, but the type system does not
    4510 enforce those restrictions. Consequently, there is no need for a separate ``array type''
    4511 specification.
    4512 
    4513 Pointer types are scalar types. Like other scalar types, they have ``\lstinline$+$'' and
     3821``\lstinline$!=$'' are only defined for pointers to array elements, but the type system does not enforce those restrictions.
     3822Consequently, there is no need for a separate ``array type'' specification.
     3823
     3824Pointer types are scalar types.
     3825Like other scalar types, they have ``\lstinline$+$'' and
    45143826``\lstinline$-$'' operators, but the types do not match the types of the operations in
    45153827\lstinline$arithmetic$, so these operators cannot be consolidated in \lstinline$scalar$.
    45163828\begin{lstlisting}
    4517 context pointer( type P | scalar( P ) ) {@\impl{pointer}@@\use{scalar}@
     3829trait pointer( type P | scalar( P ) ) {@\impl{pointer}@@\use{scalar}@
    45183830        P ?+?( P, long int ), ?+?( long int, P ), ?-?( P, long int );
    45193831        ptrdiff_t ?-?( P, P );
    45203832};
    4521 
    4522 context m_l_pointer( type P | pointer( P ) | m_l_scalar( P ) ) {@\impl{m_l_pointer}@
     3833trait m_l_pointer( type P | pointer( P ) | m_l_scalar( P ) ) {@\impl{m_l_pointer}@
    45233834        P ?+=?( P *, long int ), ?-=?( P *, long int );
    45243835        P ?=?( P *, void * );
    … …  
    45273838\end{lstlisting}
    45283839
    4529 Specifications that define the dereference operator ( or subscript operator ) require two
    4530 parameters, one for the pointer type and one for the pointed-at ( or element ) type. Different
    4531 specifications are needed for each set of \Index{type qualifier}s, because qualifiers are not
    4532 included in types. The assertion ``\lstinline$|ptr_to( Safe_pointer, int )$'' should be read as
     3840Specifications that define the dereference operator ( or subscript operator ) require two parameters, one for the pointer type and one for the pointed-at ( or element ) type.
     3841Different specifications are needed for each set of \Index{type qualifier}s, because qualifiers are not included in types.
     3842The assertion ``\lstinline$|ptr_to( Safe_pointer, int )$'' should be read as
    45333843``\lstinline$Safe_pointer$ acts like a pointer to \lstinline$int$''.
    45343844\begin{lstlisting}
    4535 context ptr_to( type P | pointer( P ), type T ) {@\impl{ptr_to}@@\use{pointer}@
    4536         lvalue T *?( P ); lvalue T ?[?]( P, long int );
     3845trait ptr_to( type P | pointer( P ), otype T ) {@\impl{ptr_to}@@\use{pointer}@
     3846        lvalue T *?( P );
     3847        lvalue T ?[?]( P, long int );
    45373848};
    4538 
    4539 context ptr_to_const( type P | pointer( P ), type T ) {@\impl{ptr_to_const}@
    4540         const lvalue T *?( P ); const lvalue T ?[?]( P, long int );@\use{pointer}@
     3849trait ptr_to_const( type P | pointer( P ), otype T ) {@\impl{ptr_to_const}@
     3850        const lvalue T *?( P );
     3851        const lvalue T ?[?]( P, long int );@\use{pointer}@
    45413852};
    4542 
    4543 context ptr_to_volatile( type P | pointer( P ), type T ) }@\impl{ptr_to_volatile}@
    4544         volatile lvalue T *?( P ); volatile lvalue T ?[?]( P, long int );@\use{pointer}@
     3853trait ptr_to_volatile( type P | pointer( P ), otype T ) }@\impl{ptr_to_volatile}@
     3854        volatile lvalue T *?( P );
     3855        volatile lvalue T ?[?]( P, long int );@\use{pointer}@
    45453856};
    4546 \end{lstlisting}
    4547 \begin{lstlisting}
    4548 context ptr_to_const_volatile( type P | pointer( P ), type T ) }@\impl{ptr_to_const_volatile}@
     3857trait ptr_to_const_volatile( type P | pointer( P ), otype T ) }@\impl{ptr_to_const_volatile}@
    45493858        const volatile lvalue T *?( P );@\use{pointer}@
    45503859        const volatile lvalue T ?[?]( P, long int );
    … …  
    45523861\end{lstlisting}
    45533862
    4554 Assignment to pointers is more complicated than is the case with other types, because the target's
    4555 type can have extra type qualifiers in the pointed-at type: a ``\lstinline$T *$'' can be assigned to
    4556 a ``\lstinline$const T *$'', a ``\lstinline$volatile T *$'', and a ``\lstinline$const volatile T *$''.
     3863Assignment to pointers is more complicated than is the case with other types, because the target's type can have extra type qualifiers in the pointed-at type: a ``\lstinline$T *$'' can be assigned to a ``\lstinline$const T *$'', a ``\lstinline$volatile T *$'', and a ``\lstinline$const volatile T *$''.
    45573864Again, the pointed-at type is passed in, so that assertions can connect these specifications to the
    45583865``\lstinline$ptr_to$'' specifications.
    45593866\begin{lstlisting}
    4560 context 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}@ {
     3867trait m_l_ptr_to( type P | m_l_pointer( P ),@\use{m_l_pointer}@@\impl{m_l_ptr_to}@ otype T | ptr_to( P, T )@\use{ptr_to}@ {
    45613868        P ?=?( P *, T * );
    45623869        T * ?=?( T **, P );
    45633870};
    4564 
    4565 context 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}@) {
     3871trait m_l_ptr_to_const( type P | m_l_pointer( P ),@\use{m_l_pointer}@@\impl{m_l_ptr_to_const}@ otype T | ptr_to_const( P, T )@\use{ptr_to_const}@) {
    45663872        P ?=?( P *, const T * );
    45673873        const T * ?=?( const T **, P );
    45683874};
    4569 
    4570 context 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}@
     3875trait m_l_ptr_to_volatile( type P | m_l_pointer( P ),@\use{m_l_pointer}@@\impl{m_l_ptr_to_volatile}@ otype T | ptr_to_volatile( P, T )) {@\use{ptr_to_volatile}@
    45713876        P ?=?( P *, volatile T * );
    45723877        volatile T * ?=?( volatile T **, P );
    45733878};
    4574 
    4575 context 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}@
     3879trait 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}@
    45763880                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}@
    45773881        P ?=?( P *, const volatile T * );
    … …  
    45803884\end{lstlisting}
    45813885
    4582 Note the regular manner in which type qualifiers appear in those specifications. An alternative
    4583 specification can make use of the fact that qualification of the pointed-at type is part of a
    4584 pointer type to capture that regularity.
    4585 \begin{lstlisting}
    4586 context 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 ) ) {
     3886Note the regular manner in which type qualifiers appear in those specifications.
     3887An alternative specification can make use of the fact that qualification of the pointed-at type is part of a pointer type to capture that regularity.
     3888\begin{lstlisting}
     3889trait 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 ) ) {
    45873890        MyP ?=?( MyP *, CP );
    45883891        CP ?=?( CP *, MyP );
    … …  
    45903893\end{lstlisting}
    45913894The assertion ``\lstinline$| m_l_ptr_like( Safe_ptr, const int * )$'' should be read as
    4592 ``\lstinline$Safe_ptr$ is a pointer type like \lstinline$const int *$''. This specification has two
    4593 defects, compared to the original four: there is no automatic assertion that dereferencing a
     3895``\lstinline$Safe_ptr$ is a pointer type like \lstinline$const int *$''.
     3896This specification has two defects, compared to the original four: there is no automatic assertion that dereferencing a
    45943897\lstinline$MyP$ produces an lvalue of the type that \lstinline$CP$ points at, and the
    4595 ``\lstinline$|m_l_pointer( CP )$'' assertion provides only a weak assurance that the argument passed
    4596 to \lstinline$CP$ really is a pointer type.
     3898``\lstinline$|m_l_pointer( CP )$'' assertion provides only a weak assurance that the argument passed to \lstinline$CP$ really is a pointer type.
    45973899
    45983900
    45993901\section{Relationships between operations}
    46003902
    4601 Different operators often have related meanings; for instance, in C, ``\lstinline$+$'',
     3903Different operators often have related meanings;
     3904for instance, in C, ``\lstinline$+$'',
    46023905``\lstinline$+=$'', and the two versions of ``\lstinline$++$'' perform variations of addition.
    4603 Languages like {\CC} and Ada allow programmers to define operators for new types, but do not
    4604 require that these relationships be preserved, or even that all of the operators be implemented.
    4605 Completeness and consistency is left to the good taste and discretion of the programmer. It is
    4606 possible to encourage these attributes by providing generic operator functions, or member functions
    4607 of abstract classes, that are defined in terms of other, related operators.
    4608 
    4609 In \CFA, polymorphic functions provide the equivalent of these generic operators, and
    4610 specifications explicitly define the minimal implementation that a programmer should provide. This
    4611 section shows a few examples.
     3906Languages like {\CC} and Ada allow programmers to define operators for new types, but do not require that these relationships be preserved, or even that all of the operators be implemented.
     3907Completeness and consistency is left to the good taste and discretion of the programmer.
     3908It is possible to encourage these attributes by providing generic operator functions, or member functions of abstract classes, that are defined in terms of other, related operators.
     3909
     3910In \CFA, polymorphic functions provide the equivalent of these generic operators, and specifications explicitly define the minimal implementation that a programmer should provide.
     3911This section shows a few examples.
    46123912
    46133913
    46143914\subsection{Relational and equality operators}
    46153915
    4616 The different comparison operators have obvious relationships, but there is no obvious subset of the
    4617 operations to use in the implementation of the others. However, it is usually convenient to
    4618 implement a single comparison function that returns a negative integer, 0, or a positive integer if
    4619 its first argument is respectively less than, equal to, or greater than its second argument; the
    4620 library function \lstinline$strcmp$ is an example.
    4621 
    4622 C and \CFA have an extra, non-obvious comparison operator: ``\lstinline$!$'', logical negation,
    4623 returns 1 if its operand compares equal to 0, and 0 otherwise.
    4624 \begin{lstlisting}
    4625 context comparable( type T ) {
     3916The different comparison operators have obvious relationships, but there is no obvious subset of the operations to use in the implementation of the others.
     3917However, it is usually convenient to implement a single comparison function that returns a negative integer, 0, or a positive integer if its first argument is respectively less than, equal to, or greater than its second argument;
     3918the library function \lstinline$strcmp$ is an example.
     3919
     3920C and \CFA have an extra, non-obvious comparison operator: ``\lstinline$!$'', logical negation, returns 1 if its operand compares equal to 0, and 0 otherwise.
     3921\begin{lstlisting}
     3922trait comparable( otype T ) {
    46263923        const T 0;
    46273924        int compare( T, T );
    46283925}
    4629 
    4630 forall( type T | comparable( T ) ) int ?<?( T l, T r ) {
     3926forall( otype T | comparable( T ) ) int ?<?( T l, T r ) {
    46313927        return compare( l, r ) < 0;
    46323928}
    46333929// ... similarly for <=, ==, >=, >, and !=.
    4634 
    4635 forall( type T | comparable( T ) ) int !?( T operand ) {
     3930forall( otype T | comparable( T ) ) int !?( T operand ) {
    46363931        return !compare( operand, 0 );
    46373932}
    … …  
    46413936\subsection{Arithmetic and integer operations}
    46423937
    4643 A complete arithmetic type would provide the arithmetic operators and the corresponding assignment
    4644 operators. Of these, the assignment operators are more likely to be implemented directly, because
    4645 it is usually more efficient to alter the contents of an existing object than to create and return a
    4646 new one. Similarly, a complete integral type would provide integral operations based on integral
    4647 assignment operations.
    4648 \begin{lstlisting}
    4649 context arith_base( type T ) {
     3938A complete arithmetic type would provide the arithmetic operators and the corresponding assignment operators.
     3939Of these, the assignment operators are more likely to be implemented directly, because it is usually more efficient to alter the contents of an existing object than to create and return a new one.
     3940Similarly, a complete integral type would provide integral operations based on integral assignment operations.
     3941\begin{lstlisting}
     3942trait arith_base( otype T ) {
    46503943        const T 1;
    46513944        T ?+=?( T *, T ), ?-=?( T *, T ), ?*=?( T *, T ), ?/=?( T *, T );
    46523945}
    4653 
    4654 forall( type T | arith_base( T ) ) T ?+?( T l, T r ) {
     3946forall( otype T | arith_base( T ) ) T ?+?( T l, T r ) {
    46553947        return l += r;
    46563948}
    4657 
    4658 forall( type T | arith_base( T ) ) T ?++( T * operand ) {
     3949forall( otype T | arith_base( T ) ) T ?++( T * operand ) {
    46593950        T temporary = *operand;
    46603951        *operand += 1;
    46613952        return temporary;
    46623953}
    4663 
    4664 forall( type T | arith_base( T ) ) T ++?( T * operand ) {
     3954forall( otype T | arith_base( T ) ) T ++?( T * operand ) {
    46653955        return *operand += 1;
    46663956}
    46673957// ... similarly for -, --, *, and /.
    4668 
    4669 context int_base( type T ) {
     3958trait int_base( otype T ) {
    46703959        T ?&=?( T *, T ), ?|=?( T *, T ), ?^=?( T *, T );
    46713960        T ?%=?( T *, T ), ?<<=?( T *, T ), ?>>=?( T *, T );
    46723961}
    4673 
    4674 forall( type T | int_base( T ) ) T ?&?( T l, T r ) {
     3962forall( otype T | int_base( T ) ) T ?&?( T l, T r ) {
    46753963        return l &= r;
    46763964}
    … …  
    46783966\end{lstlisting}
    46793967
    4680 Note that, although an arithmetic type would certainly provide comparison functions, and an integral
    4681 type would provide arithmetic operations, there does not have to be any relationship among
    4682 \lstinline$int_base$, \lstinline$arith_base$ and \lstinline$comparable$. Note also that these
    4683 declarations provide guidance and assistance, but they do not define an absolutely minimal set of
    4684 requirements. A truly minimal implementation of an arithmetic type might only provide
     3968Note that, although an arithmetic type would certainly provide comparison functions, and an integral type would provide arithmetic operations, there does not have to be any relationship among
     3969\lstinline$int_base$, \lstinline$arith_base$ and \lstinline$comparable$.
     3970Note also that these declarations provide guidance and assistance, but they do not define an absolutely minimal set of requirements.
     3971A truly minimal implementation of an arithmetic type might only provide
    46853972\lstinline$0$, \lstinline$1$, and \lstinline$?-=?$, which would be used by polymorphic
    46863973\lstinline$?+=?$, \lstinline$?*=?$, and \lstinline$?/=?$ functions.
    … …  
    46923979Review index entries.
    46933980
    4694 Restrict allowed to qualify anything, or type/dtype parameters, but only affects pointers. This gets
    4695 into \lstinline$noalias$ territory. Qualifying anything (``\lstinline$short restrict rs$'') means
    4696 pointer parameters of \lstinline$?++$, etc, would need restrict qualifiers.
    4697 
    4698 Enumerated types. Constants are not ints. Overloading. Definition should be ``representable as an
    4699 integer type'', not ``as an int''. C11 usual conversions freely convert to and from ordinary
    4700 integer types via assignment, which works between any integer types. Does enum Color ?*?( enum
     3981Restrict allowed to qualify anything, or type/dtype parameters, but only affects pointers.
     3982This gets into \lstinline$noalias$ territory.
     3983Qualifying anything (``\lstinline$short restrict rs$'') means pointer parameters of \lstinline$?++$, etc, would need restrict qualifiers.
     3984
     3985Enumerated types.
     3986Constants are not ints.
     3987Overloading.
     3988Definition should be ``representable as an integer type'', not ``as an int''.
     3989C11 usual conversions freely convert to and from ordinary integer types via assignment, which works between any integer types.
     3990Does enum Color ?*?( enum
    47013991Color, enum Color ) really make sense? ?++ does, but it adds (int)1.
    47023992
    4703 Operators on {,signed,unsigned} char and other small types. ?<? harmless; ?*? questionable for
    4704 chars. Generic selections make these choices visible. Safe conversion operators? Predefined
     3993Operators on {,signed,unsigned} char and other small types. ?<? harmless;
     3994?*? questionable for chars.
     3995Generic selections make these choices visible.
     3996Safe conversion operators? Predefined
    47053997``promotion'' function?
    47063998
    4707 \lstinline$register$ assignment might be handled as assignment to a temporary with copying back and
    4708 forth, but copying must not be done by assignment.
     3999\lstinline$register$ assignment might be handled as assignment to a temporary with copying back and forth, but copying must not be done by assignment.
    47094000
    47104001Don't use ptrdiff\_t by name in the predefineds.
    47114002
    4712 Polymorphic objects. Polymorphic typedefs and type declarations.
     4003Polymorphic objects.
     4004Polymorphic typedefs and type declarations.
    47134005
    47144006
    … …  
    47194011\addcontentsline{toc}{chapter}{\indexname} % add index name to table of contents
    47204012\begin{theindex}
    4721 Italic page numbers give the location of the main entry for the referenced term. Plain page numbers
    4722 denote uses of the indexed term. Entries for grammar non-terminals are italicized. A typewriter
    4723 font is used for grammar terminals and program identifiers.
     4013Italic page numbers give the location of the main entry for the referenced term.
     4014Plain page numbers denote uses of the indexed term.
     4015Entries for grammar non-terminals are italicized.
     4016A typewriter font is used for grammar terminals and program identifiers.
    47244017\indexspace
    47254018\input{refrat.ind}

  • src/CodeGen/CodeGenerator.cc

    r39786813 ra5a71d0  
    1010// Created On       : Mon May 18 07:44:20 2015
    1111// Last Modified By : Rob Schluntz
    12 // Last Modified On : Wed Mar 30 14:39:30 2016
     12// Last Modified On : Mon Apr 04 17:08:06 2016
    1313// Update Count     : 255
    1414//
    … …  
    2121#include "Parser/ParseNode.h"
    2222
    23 #include "SynTree/Type.h"
     23#include "SynTree/Declaration.h"
    2424#include "SynTree/Expression.h"
    2525#include "SynTree/Initializer.h"
    2626#include "SynTree/Statement.h"
     27#include "SynTree/Type.h"
    2728
    2829#include "Common/utility.h"
    … …  
    170171        }
    171172
    172         void CodeGenerator::visit( ContextDecl *aggregateDecl ) {}
     173        void CodeGenerator::visit( TraitDecl *aggregateDecl ) {}
    173174
    174175        void CodeGenerator::visit( TypedefDecl *typeDecl ) {

  • src/CodeGen/CodeGenerator.h

    r39786813 ra5a71d0  
    99// Author           : Richard C. Bilson
    1010// Created On       : Mon May 18 07:44:20 2015
    11 // Last Modified By : Rob Schluntz
    12 // Last Modified On : Wed Aug 12 14:27:14 2015
    13 // Update Count     : 27
     11// Last Modified By : Peter A. Buhr
     12// Last Modified On : Wed Mar  2 17:32:24 2016
     13// Update Count     : 28
    1414//
    1515
    … …  
    1919#include <list>
    2020
     21#include "SynTree/Declaration.h"
    2122#include "SynTree/SynTree.h"
    2223#include "SynTree/Visitor.h"
     24
    2325#include "SymTab/Indexer.h"
    2426
    … …  
    3840                virtual void visit( UnionDecl *aggregateDecl );
    3941                virtual void visit( EnumDecl *aggregateDecl );
    40                 virtual void visit( ContextDecl *aggregateDecl );
     42                virtual void visit( TraitDecl *aggregateDecl );