Changes in / [59cde21:b0be06ac]


Ignore:
Files:
4 added
3 deleted
10 edited

Legend:

Unmodified
Added
Removed

  • .gitignore

    r59cde21 rb0be06ac  
    2727# generated by bison and lex from cfa.yy and lex.ll, respectively
    2828src/Parser/parser.output
     29
     30# generated by latex
     31doc/refrat/refrat.aux
     32doc/refrat/refrat.bbl
     33doc/refrat/refrat.blg
     34doc/refrat/refrat.brf
     35doc/refrat/refrat.dvi
     36doc/refrat/refrat.idx
     37doc/refrat/refrat.ilg
     38doc/refrat/refrat.ind
     39doc/refrat/refrat.log
     40doc/refrat/refrat.out
     41doc/refrat/refrat.pdf
     42doc/refrat/refrat.ps
     43doc/refrat/refrat.toc

  • doc/refrat/refrat.tex

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

  • src/CodeGen/CodeGenerator.cc

    r59cde21 rb0be06ac  
    1010// Created On       : Mon May 18 07:44:20 2015
    1111// Last Modified By : Rob Schluntz
    12 // Last Modified On : Wed Aug 12 14:33:52 2015
    13 // Update Count     : 222
     12// Last Modified On : Thu Sep 17 15:25:58 2015
     13// Update Count     : 233
    1414//
    1515
    … …  
    190190                if ( designators.size() == 0 ) return;
    191191                for ( DesignatorList::iterator iter = designators.begin(); iter != designators.end(); ++iter ) {
    192                         if ( NameExpr * nm = dynamic_cast< NameExpr * >( *iter ) ) {
     192                        if ( dynamic_cast< NameExpr * >( *iter ) ) {
    193193                                // if expression is a name, then initializing aggregate member
    194194                                output << ".";
    … …  
    258258             
    259259                                  case OT_CALL:
    260                                         // there are no intrinsic definitions of the function call operator
     260                                  case OT_CTOR:
     261                                  case OT_DTOR:
     262                                        // there are no intrinsic definitions of the function call operator or constructors or destructors
    261263                                        assert( false );
    262264                                        break;
    … …  
    322324             
    323325                                  case OT_CALL:
     326                                        case OT_CTOR:
     327                                        case OT_DTOR:
    324328                                        assert( false );
    325329                                        break;
    … …  
    392396
    393397        void CodeGenerator::visit( CastExpr *castExpr ) {
    394                 output << "((";
    395                 if ( castExpr->get_results().empty() ) {
    396                         output << "void" ;
    397                 } else {
    398                         output << genType( castExpr->get_results().front(), "" );
    399                 } // if
    400                 output << ")";
    401                 castExpr->get_arg()->accept( *this );
    402                 output << ")";
     398                // if the cast is to an lvalue type, then the cast
     399                // should be dropped, since the result of a cast is
     400                // never an lvalue in C
     401                if ( castExpr->get_results().front()->get_isLvalue() ) {
     402                        castExpr->get_arg()->accept( *this );
     403                } else {
     404                        output << "((";
     405                        if ( castExpr->get_results().empty() ) {
     406                                output << "void" ;
     407                        } else {
     408                                output << genType( castExpr->get_results().front(), "" );
     409                        } // if
     410                        output << ")";
     411                        castExpr->get_arg()->accept( *this );
     412                        output << ")";                 
     413                }
    403414        }
    404415 

  • src/CodeGen/OperatorTable.cc

    r59cde21 rb0be06ac  
    99// Author           : Richard C. Bilson
    1010// Created On       : Mon May 18 07:44:20 2015
    11 // Last Modified By : Peter A. Buhr
    12 // Last Modified On : Tue Jun 23 17:41:14 2015
    13 // Update Count     : 5
     11// Last Modified By : Rob Schluntz
     12// Last Modified On : Tue Oct 06 15:26:34 2015
     13// Update Count     : 9
    1414//
    1515
    … …  
    2121                const OperatorInfo tableValues[] = {
    2222                        {       "?[?]",         "",             "_operator_index",                              OT_INDEX                        },
     23                        {       "?{}",          "",             "_constructor",                                 OT_CTOR                         },
     24                        {       "^?{}",         "",             "_destructor",                                  OT_DTOR                         }, // ~?{}, -?{}, !?{}, $?{}, ??{}, ^?{}, ?destroy, ?delete
    2325                        {       "?()",          "",             "_operator_call",                               OT_CALL                         },
    2426                        {       "?++",          "++",   "_operator_postincr",                   OT_POSTFIXASSIGN        },

  • src/CodeGen/OperatorTable.h

    r59cde21 rb0be06ac  
    99// Author           : Richard C. Bilson
    1010// Created On       : Mon May 18 07:44:20 2015
    11 // Last Modified By : Peter A. Buhr
    12 // Last Modified On : Tue Jun 23 16:09:27 2015
    13 // Update Count     : 3
     11// Last Modified By : Rob Schluntz
     12// Last Modified On : Wed Jun 24 16:17:57 2015
     13// Update Count     : 5
    1414//
    1515
    … …  
    2222        enum OperatorType {
    2323                OT_INDEX,
     24                OT_CTOR,
     25                OT_DTOR,
    2426                OT_CALL,
    2527                OT_PREFIX,

  • src/GenPoly/Specialize.cc

    r59cde21 rb0be06ac  
    99// Author           : Richard C. Bilson
    1010// Created On       : Mon May 18 07:44:20 2015
    11 // Last Modified By : Peter A. Buhr
    12 // Last Modified On : Sat Jun 13 15:54:07 2015
    13 // Update Count     : 6
     11// Last Modified By : Rob Schluntz
     12// Last Modified On : Tue Sep 22 14:04:13 2015
     13// Update Count     : 15
    1414//
    1515
    … …  
    8686
    8787        Expression * Specialize::doSpecialization( Type *formalType, Expression *actual, InferredParams *inferParams ) {
     88                assert( ! actual->get_results().empty() );
    8889                if ( needsSpecialization( formalType, actual->get_results().front(), env ) ) {
    8990                        PointerType *ptrType;
    … …  
    167168        Expression * Specialize::mutate( AddressExpr *addrExpr ) {
    168169                addrExpr->get_arg()->acceptMutator( *this );
     170                assert( ! addrExpr->get_results().empty() );
    169171                addrExpr->set_arg( doSpecialization( addrExpr->get_results().front(), addrExpr->get_arg() ) );
    170172                return addrExpr;
    … …  
    173175        Expression * Specialize::mutate( CastExpr *castExpr ) {
    174176                castExpr->get_arg()->acceptMutator( *this );
    175                 castExpr->set_arg( doSpecialization( castExpr->get_results().front(), castExpr->get_arg() ) );
     177                if ( ! castExpr->get_results().empty() ) {
     178                        // this may not be the correct condition, but previously the next statement
     179                        // was happening unchecked, causing a crash on a cast to void
     180                        castExpr->set_arg( doSpecialization( castExpr->get_results().front(), castExpr->get_arg() ) );         
     181                }
    176182                return castExpr;
    177183        }

  • src/MakeLibCfa.cc

    r59cde21 rb0be06ac  
    99// Author           : Richard C. Bilson
    1010// Created On       : Sat May 16 10:33:33 2015
    11 // Last Modified By : Peter A. Buhr
    12 // Last Modified On : Fri Jun 26 16:52:59 2015
    13 // Update Count     : 14
     11// Last Modified By : Rob Schluntz
     12// Last Modified On : Fri Jul 03 18:11:37 2015
     13// Update Count     : 18
    1414//
    1515
    … …  
    7777                                break;
    7878                        }
     79                  case CodeGen::OT_CTOR:
     80                  case CodeGen::OT_DTOR:
    7981                  case CodeGen::OT_CONSTANT:
    8082                  case CodeGen::OT_LABELADDRESS:

  • src/Parser/ParseNode.h

    r59cde21 rb0be06ac  
    1010// Created On       : Sat May 16 13:28:16 2015
    1111// Last Modified By : Rob Schluntz
    12 // Last Modified On : Wed Aug 12 13:27:11 2015
    13 // Update Count     : 172
     12// Last Modified On : Wed Aug 19 15:59:27 2015
     13// Update Count     : 174
    1414//
    1515
    … …  
    180180                                Assign, MulAssn, DivAssn, ModAssn, PlusAssn, MinusAssn, LSAssn, RSAssn, AndAssn,
    181181                                ERAssn, OrAssn, Index, FieldSel, PFieldSel, Range,
    182                                 UnPlus, UnMinus, AddressOf, PointTo, Neg, BitNeg, Incr, IncrPost, Decr, DecrPost, LabelAddress
     182                                UnPlus, UnMinus, AddressOf, PointTo, Neg, BitNeg, Incr, IncrPost, Decr, DecrPost, LabelAddress,
     183                                Ctor, Dtor,
    183184        };
    184185

  • src/SymTab/Indexer.h

    r59cde21 rb0be06ac  
    1010// Created On       : Sun May 17 21:38:55 2015
    1111// Last Modified By : Rob Schluntz
    12 // Last Modified On : Wed Aug 05 13:51:39 2015
    13 // Update Count     : 4
     12// Last Modified On : Thu Sep 17 16:05:38 2015
     13// Update Count     : 5
    1414//
    1515
    … …  
    1919#include <list>
    2020#include <string>
    21 #include <map>
    2221
    2322#include "SynTree/Visitor.h"

  • src/SynTree/Expression.cc

    r59cde21 rb0be06ac  
    1010// Created On       : Mon May 18 07:44:20 2015
    1111// Last Modified By : Rob Schluntz
    12 // Last Modified On : Wed Aug 12 14:02:45 2015
    13 // Update Count     : 30
     12// Last Modified On : Wed Sep 02 12:07:10 2015
     13// Update Count     : 33
    1414//
    1515
    … …  
    3131Expression::Expression( Expression *_aname ) : env( 0 ), argName( _aname ) {}
    3232
    33 Expression::Expression( const Expression &other ) : env( maybeClone( other.env ) ) {
     33Expression::Expression( const Expression &other ) : env( maybeClone( other.env ) ), argName( maybeClone( other.get_argName() ) ) {
    3434        cloneAll( other.results, results );
    35         argName = other.get_argName();
    3635}
    3736
Note: See TracChangeset for help on using the changeset viewer.