Changeset 0638c44 for doc/refrat


Ignore:
Timestamp:
May 3, 2016, 9:30:55 AM (6 years ago)
Author:
Peter A. Buhr <pabuhr@…>
Branches:
aaron-thesis, arm-eh, cleanup-dtors, ctor, deferred_resn, demangler, gc_noraii, jacob/cs343-translation, jenkins-sandbox, master, memory, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, resolv-new, with_gc
Children:
7937abf, a1d6d80
Parents:
e945826
Message:

more formatting changes to documents, update I/O for examples

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/refrat/refrat.tex

    re945826 r0638c44  
    1 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -*- Mode: Latex -*- %%%%%%%%%%%%%%%%%%%%%%%%%%%%
    2 %%
     1%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -*- Mode: Latex -*- %%%%%%%%%%%%%%%%%%%%%%%%%%%%``%%
    32%% Cforall Version 1.0.0 Copyright (C) 2016 University of Waterloo
    43%%
     
    1110%% Created On       : Wed Apr  6 14:52:25 2016
    1211%% Last Modified By : Peter A. Buhr
    13 %% Last Modified On : Sat Apr 30 13:45:40 2016
    14 %% Update Count     : 29
     12%% Last Modified On : Tue May  3 09:23:43 2016
     13%% Update Count     : 52
    1514%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    1615
    1716% requires tex packages: texlive-base texlive-latex-base tex-common texlive-humanities texlive-latex-extra texlive-fonts-recommended
    1817
    19 % red highlighting ®...® (registered trademark sumbol)
    20 % blue highlighting ©...© (copyright symbol)
    21 % latex escape §...§ (section symbol)
    22 % keyword escape ¶...¶ (pilcrow symbol)
     18% inline code ©...© (copyright symbol) emacs: C-q M-)
     19% red highlighting ®...® (registered trademark sumbol) emacs: C-q M-.
     20% latex escape §...§ (section symbol) emacs: C-q M-'
     21% keyword escape ¶...¶ (pilcrow symbol) emacs: C-q M-^
    2322% math escape $...$ (dollar symbol)
    2423
     
    2726
    2827% Latex packages used in the document.
     28\usepackage[T1]{fontenc}                                % allow Latin1 (extended ASCII) characters
     29\usepackage{textcomp}
     30\usepackage[latin1]{inputenc}
     31\usepackage{upquote}
    2932\usepackage{fullpage,times}
     33\usepackage{epic,eepic}
    3034\usepackage{xspace}
    3135\usepackage{varioref}
     
    4751%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    4852
     53% Names used in the document.
     54
     55\newcommand{\Version}{1.0.0}
     56
     57%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
     58
    4959\setcounter{secnumdepth}{3}                             % number subsubsections
    5060\setcounter{tocdepth}{3}                                % subsubsections in table of contents
     
    131141\CFA's scope rules differ from C's in one major respect: a declaration of an identifier may overload\index{overloading} outer declarations of lexically identical identifiers in the same
    132142\Index{name space}, instead of hiding them.
    133 The outer declaration is hidden if the two declarations have \Index{compatible type}, or if one declares an array type and the other declares a pointer type and the element type and pointed-at type are compatible, or if one has function type and the other is a pointer to a compatible function type, or if one declaration is a \lstinline@type@\use{type} or
    134 \lstinline@typedef@\use{typedef} declaration and the other is not.  The outer declaration becomes
    135 \Index{visible} when the scope of the inner declaration terminates.
    136 \begin{rationale}
    137 Hence, a \CFA program can declare an \lstinline@int v@ and a \lstinline@float v@ in the same scope;
     143The outer declaration is hidden if the two declarations have \Index{compatible type}, or if one declares an array type and the other declares a pointer type and the element type and pointed-at type are compatible, or if one has function type and the other is a pointer to a compatible function type, or if one declaration is a ©type©\use{type} or ©typedef©\use{typedef} declaration and the other is not.
     144The outer declaration becomes \Index{visible} when the scope of the inner declaration terminates.
     145\begin{rationale}
     146Hence, a \CFA program can declare an ©int v© and a ©float v© in the same scope;
    138147a {\CC} program can not.
    139148\end{rationale}
     
    149158Identifiers with \Index{no linkage} always denote unique entities.
    150159\begin{rationale}
    151 A \CFA program can declare an \lstinline@extern int v@ and an \lstinline@extern float v@;
     160A \CFA program can declare an ©extern int v© and an ©extern float v©;
    152161a C program cannot.
    153162\end{rationale}
     
    172181\end{lstlisting}
    173182
    174 The type parameters in an instantiation of a generic type must satisfy any constraints in the forall specifier on the type generator declaration, e.g., \lstinline@sumable@.
     183The type parameters in an instantiation of a generic type must satisfy any constraints in the forall specifier on the type generator declaration, e.g., ©sumable©.
    175184The instantiation then has the semantics that would result if the type parameters were substituted into the type generator declaration by macro substitution.
    176185
     
    233242In \CFA, these conversions play a role in overload resolution, and collectively are called the \define{safe arithmetic conversion}s.
    234243
    235 Let \lstinline@int$_r$@ and \lstinline@unsigned$_r$@ be the signed and unsigned integer types with integer conversion rank\index{integer conversion rank}\index{rank|see{integer conversion rank}} $r$.
    236 Let \lstinline@unsigned$_{mr}$@ be the unsigned integer type with maximal rank.
     244Let ©int$_r$© and ©unsigned$_r$© be the signed and unsigned integer types with integer conversion rank\index{integer conversion rank}\index{rank|see{integer conversion rank}} $r$.
     245Let ©unsigned$_{mr}$© be the unsigned integer type with maximal rank.
    237246
    238247The following conversions are \emph{direct} safe arithmetic conversions.
     
    241250The \Index{integer promotion}s.
    242251\item
    243 For every rank $r$ greater than or equal to the rank of \lstinline@int@, conversion from \lstinline@int$_r$@ to \lstinline@unsigned$_r$@.
    244 \item
    245 For every rank $r$ greater than or equal to the rank of \lstinline@int@, where \lstinline@int$_{r+1}$@ exists and can represent all values of \lstinline@unsigned$_r$@, conversion from \lstinline@unsigned$_r$@ to \lstinline@int$_{r+1}$@.
    246 \item
    247 Conversion from \lstinline@unsigned$_{mr}$@ to \lstinline@float@.
     252For every rank $r$ greater than or equal to the rank of ©int©, conversion from ©int$_r$© to ©unsigned$_r$©.
     253\item
     254For every rank $r$ greater than or equal to the rank of ©int©, where ©int$_{r+1}$© exists and can represent all values of ©unsigned$_r$©, conversion from ©unsigned$_r$© to ©int$_{r+1}$©.
     255\item
     256Conversion from ©unsigned$_{mr}$© to ©float©.
    248257\item
    249258Conversion from an enumerated type to its compatible integer type.
    250259\item
    251 Conversion from \lstinline@float@ to \lstinline@double@, and from \lstinline@double@ to \lstinline@long double@.
    252 \item
    253 Conversion from \lstinline@float _Complex@ to \lstinline@double _Complex@, and from \lstinline@double _Complex@ to \lstinline@long double _Complex@.
     260Conversion from ©float© to ©double©, and from ©double© to ©long double©.
     261\item
     262Conversion from ©float _Complex© to ©double _Complex©, and from ©double _Complex© to ©long double _Complex©.
    254263\begin{sloppypar}
    255264\item
    256 Conversion from \lstinline@float _Imaginary@ to \lstinline@double _Imaginary@, and from \lstinline@double _Imaginary@ to \lstinline@long double _Imaginary@, if the implementation supports imaginary types.
     265Conversion from ©float _Imaginary© to ©double _Imaginary©, and from ©double _Imaginary© to ©long double _Imaginary©, if the implementation supports imaginary types.
    257266\end{sloppypar}
    258267\end{itemize}
    259268
    260 If type \lstinline@T@ can be converted to type \lstinline@U@ by a safe direct arithmetic conversion and type \lstinline@U@ can be converted to type \lstinline@V@ by a safe arithmetic conversion, then the conversion from \lstinline@T@ to type \lstinline@V@ is an \emph{indirect} safe arithmetic conversion.
     269If type ©T© can be converted to type ©U© by a safe direct arithmetic conversion and type ©U© can be converted to type ©V© by a safe arithmetic conversion, then the conversion from ©T© to type ©V© is an \emph{indirect} safe arithmetic conversion.
    261270
    262271\begin{rationale}
     
    291300move_to( &cp1, &cp2 );
    292301\end{lstlisting}
    293 Thanks to implicit conversion, the two arguments that \lstinline@move_by()@ receives are pointers to
    294 \lstinline@cp1@'s second member and \lstinline@cp2@'s second member.
     302Thanks to implicit conversion, the two arguments that ©move_by()© receives are pointers to ©cp1©'s second member and ©cp2©'s second member.
    295303
    296304
     
    334342a direct safe arithmetic conversion;
    335343\item
    336 from any object type or incomplete type to \lstinline@void@;
    337 \item
    338 from a pointer to any non-\lstinline@void@ type to a pointer to \lstinline@void@;
     344from any object type or incomplete type to ©void©;
     345\item
     346from a pointer to any non-©void© type to a pointer to ©void©;
    339347\item
    340348from a pointer to any type to a pointer to a more qualified version of the type\index{qualified type};
     
    347355Conversions that are not safe conversions are \define{unsafe conversion}s.
    348356\begin{rationale}
    349 As in C, there is an implicit conversion from \lstinline@void *@ to any pointer type.
     357As in C, there is an implicit conversion from ©void *© to any pointer type.
    350358This is clearly dangerous, and {\CC} does not have this implicit conversion.
    351359\CFA\index{deficiencies!void * conversion} keeps it, in the interest of remaining as pure a superset of C as possible, but discourages it by making it unsafe.
     
    373381\begin{itemize}
    374382\item
    375 The cost of an implicit conversion from \lstinline@int@ to \lstinline@long@ is 1.
    376 The cost of an implicit conversion from \lstinline@long@ to \lstinline@double@ is 3, because it is defined in terms of conversions from \lstinline@long@ to \lstinline@unsigned long@, then to \lstinline@float@, and then to \lstinline@double@.
    377 
    378 \item
    379 If \lstinline@int@ can represent all the values of \lstinline@unsigned short@, then the cost of an implicit conversion from \lstinline@unsigned short@ to \lstinline@unsigned@ is 2:
    380 \lstinline@unsigned short@ to \lstinline@int@ to \lstinline@unsigned@.
    381 Otherwise, \lstinline@unsigned short@ is converted directly to \lstinline@unsigned@, and the cost is 1.
    382 
    383 \item
    384 If \lstinline@long@ can represent all the values of \lstinline@unsigned@, then the conversion cost of \lstinline@unsigned@ to \lstinline@long@ is 1.
     383The cost of an implicit conversion from ©int© to ©long© is 1.
     384The cost of an implicit conversion from ©long© to ©double© is 3, because it is defined in terms of conversions from ©long© to ©unsigned long©, then to ©float©, and then to ©double©.
     385
     386\item
     387If ©int© can represent all the values of ©unsigned short©, then the cost of an implicit conversion from ©unsigned short© to ©unsigned© is 2: ©unsigned short© to ©int© to ©unsigned©.
     388Otherwise, ©unsigned short© is converted directly to ©unsigned©, and the cost is 1.
     389
     390\item
     391If ©long© can represent all the values of ©unsigned©, then the conversion cost of ©unsigned© to ©long© is 1.
    385392Otherwise, the conversion is an unsafe conversion, and its conversion cost is undefined.
    386393\end{itemize}
     
    390397\begin{syntax}
    391398\oldlhs{keyword}
    392         \rhs \lstinline@forall@
    393         \rhs \lstinline@lvalue@
    394         \rhs \lstinline@trait@
    395         \rhs \lstinline@dtype@
    396         \rhs \lstinline@ftype@
    397         \rhs \lstinline@otype@
     399        \rhs ©forall©
     400        \rhs ©lvalue©
     401        \rhs ©trait©
     402        \rhs ©dtype©
     403        \rhs ©ftype©
     404        \rhs ©otype©
    398405\end{syntax}
    399406
     
    402409
    403410\CFA allows operator \Index{overloading} by associating operators with special function identifiers.
    404 Furthermore, the constants ``\lstinline@0@'' and ``\lstinline@1@'' have special status for many of C's data types (and for many programmer-defined data types as well), so \CFA treats them as overloadable identifiers.
     411Furthermore, the constants ``©0©'' and ``©1©'' have special status for many of C's data types (and for many programmer-defined data types as well), so \CFA treats them as overloadable identifiers.
    405412Programmers can use these identifiers to declare functions and objects that implement operators and constants for their own types.
    406413
     
    411418\begin{syntax}
    412419\oldlhs{identifier}
    413 \rhs \lstinline@0@
    414 \rhs \lstinline@1@
     420\rhs ©0©
     421\rhs ©1©
    415422\end{syntax}
    416423
    417 \index{constant identifiers}\index{identifiers!for constants} The tokens ``\lstinline@0@''\impl{0} and ``\lstinline@1@''\impl{1} are identifiers.
     424\index{constant identifiers}\index{identifiers!for constants} The tokens ``©0©''\impl{0} and ``©1©''\impl{1} are identifiers.
    418425No other tokens defined by the rules for integer constants are considered to be identifiers.
    419426\begin{rationale}
    420 Why ``\lstinline@0@'' and ``\lstinline@1@''? Those integers have special status in C.
     427Why ``©0©'' and ``©1©''? Those integers have special status in C.
    421428All scalar types can be incremented and decremented, which is defined in terms of adding or subtracting 1.
    422 The operations ``\lstinline@&&@'', ``\lstinline@||@'', and ``\lstinline@!@'' can be applied to any scalar arguments, and are defined in terms of comparison against 0.
     429The operations ``©&&©'', ``©||©'', and ``©!©'' can be applied to any scalar arguments, and are defined in terms of comparison against 0.
    423430A \nonterm{constant-expression} that evaluates to 0 is effectively compatible with every pointer type.
    424431
    425432In C, the integer constants 0 and 1 suffice because the integer promotion rules can convert them to any arithmetic type, and the rules for pointer expressions treat constant expressions evaluating to 0 as a special case.
    426433However, user-defined arithmetic types often need the equivalent of a 1 or 0 for their functions or operators, polymorphic functions often need 0 and 1 constants of a type matching their polymorphic parameters, and user-defined pointer-like types may need a null value.
    427 Defining special constants for a user-defined type is more efficient than defining a conversion to the type from \lstinline@_Bool@.
    428 
    429 Why \emph{just} ``\lstinline@0@'' and ``\lstinline@1@''? Why not other integers? No other integers have special status in C.
    430 A facility that let programmers declare specific constants---``\lstinline@const Rational 12@'', for instance---would not be much of an improvement.
     434Defining special constants for a user-defined type is more efficient than defining a conversion to the type from ©_Bool©.
     435
     436Why \emph{just} ``©0©'' and ``©1©''? Why not other integers? No other integers have special status in C.
     437A facility that let programmers declare specific constants---``©const Rational 12©'', for instance---would not be much of an improvement.
    431438Some facility for defining the creation of values of programmer-defined types from arbitrary integer tokens would be needed.
    432439The complexity of such a feature doesn't seem worth the gain.
     
    444451\begin{tabular}[t]{ll}
    445452%identifier & operation \\ \hline
    446 \lstinline@?[?]@ & subscripting \impl{?[?]}\\
    447 \lstinline@?()@ & function call \impl{?()}\\
    448 \lstinline@?++@ & postfix increment \impl{?++}\\
    449 \lstinline@?--@ & postfix decrement \impl{?--}\\
    450 \lstinline@++?@ & prefix increment \impl{++?}\\
    451 \lstinline@--?@ & prefix decrement \impl{--?}\\
    452 \lstinline@*?@ & dereference \impl{*?}\\
    453 \lstinline@+?@ & unary plus \impl{+?}\\
    454 \lstinline@-?@ & arithmetic negation \impl{-?}\\
    455 \lstinline@~?@ & bitwise negation \impl{~?}\\
    456 \lstinline@!?@ & logical complement \impl{"!?}\\
    457 \lstinline@?*?@ & multiplication \impl{?*?}\\
    458 \lstinline@?/?@ & division \impl{?/?}\\
     453©?[?]© & subscripting \impl{?[?]}\\
     454©?()© & function call \impl{?()}\\
     455©?++© & postfix increment \impl{?++}\\
     456©?--© & postfix decrement \impl{?--}\\
     457©++?© & prefix increment \impl{++?}\\
     458©--?© & prefix decrement \impl{--?}\\
     459©*?© & dereference \impl{*?}\\
     460©+?© & unary plus \impl{+?}\\
     461©-?© & arithmetic negation \impl{-?}\\
     462©~?© & bitwise negation \impl{~?}\\
     463©!?© & logical complement \impl{"!?}\\
     464©?*?© & multiplication \impl{?*?}\\
     465©?/?© & division \impl{?/?}\\
    459466\end{tabular}\hfil
    460467\begin{tabular}[t]{ll}
    461468%identifier & operation \\ \hline
    462 \lstinline@?%?@ & remainder \impl{?%?}\\
    463 \lstinline@?+?@ & addition \impl{?+?}\\
    464 \lstinline@?-?@ & subtraction \impl{?-?}\\
    465 \lstinline@?<<?@ & left shift \impl{?<<?}\\
    466 \lstinline@?>>?@ & right shift \impl{?>>?}\\
    467 \lstinline@?<?@ & less than \impl{?<?}\\
    468 \lstinline@?<=?@ & less than or equal \impl{?<=?}\\
    469 \lstinline@?>=?@ & greater than or equal \impl{?>=?}\\
    470 \lstinline@?>?@ & greater than \impl{?>?}\\
    471 \lstinline@?==?@ & equality \impl{?==?}\\
    472 \lstinline@?!=?@ & inequality \impl{?"!=?}\\
    473 \lstinline@?&?@ & bitwise AND \impl{?&?}\\
     469©?%?© & remainder \impl{?%?}\\
     470©?+?© & addition \impl{?+?}\\
     471©?-?© & subtraction \impl{?-?}\\
     472©?<<?© & left shift \impl{?<<?}\\
     473©?>>?© & right shift \impl{?>>?}\\
     474©?<?© & less than \impl{?<?}\\
     475©?<=?© & less than or equal \impl{?<=?}\\
     476©?>=?© & greater than or equal \impl{?>=?}\\
     477©?>?© & greater than \impl{?>?}\\
     478©?==?© & equality \impl{?==?}\\
     479©?!=?© & inequality \impl{?"!=?}\\
     480©?&?© & bitwise AND \impl{?&?}\\
    474481\end{tabular}\hfil
    475482\begin{tabular}[t]{ll}
    476483%identifier & operation \\ \hline
    477 \lstinline@?^?@ & exclusive OR \impl{?^?}\\
    478 \lstinline@?|?@ & inclusive OR \impl{?"|?}\\
    479 \lstinline@?=?@ & simple assignment \impl{?=?}\\
    480 \lstinline@?*=?@ & multiplication assignment \impl{?*=?}\\
    481 \lstinline@?/=?@ & division assignment \impl{?/=?}\\
    482 \lstinline@?%=?@ & remainder assignment \impl{?%=?}\\
    483 \lstinline@?+=?@ & addition assignment \impl{?+=?}\\
    484 \lstinline@?-=?@ & subtraction assignment \impl{?-=?}\\
    485 \lstinline@?<<=?@ & left-shift assignment \impl{?<<=?}\\
    486 \lstinline@?>>=?@ & right-shift assignment \impl{?>>=?}\\
    487 \lstinline@?&=?@ & bitwise AND assignment \impl{?&=?}\\
    488 \lstinline@?^=?@ & exclusive OR assignment \impl{?^=?}\\
    489 \lstinline@?|=?@ & inclusive OR assignment \impl{?"|=?}\\
     484©?^?© & exclusive OR \impl{?^?}\\
     485©?|?© & inclusive OR \impl{?"|?}\\
     486©?=?© & simple assignment \impl{?=?}\\
     487©?*=?© & multiplication assignment \impl{?*=?}\\
     488©?/=?© & division assignment \impl{?/=?}\\
     489©?%=?© & remainder assignment \impl{?%=?}\\
     490©?+=?© & addition assignment \impl{?+=?}\\
     491©?-=?© & subtraction assignment \impl{?-=?}\\
     492©?<<=?© & left-shift assignment \impl{?<<=?}\\
     493©?>>=?© & right-shift assignment \impl{?>>=?}\\
     494©?&=?© & bitwise AND assignment \impl{?&=?}\\
     495©?^=?© & exclusive OR assignment \impl{?^=?}\\
     496©?|=?© & inclusive OR assignment \impl{?"|=?}\\
    490497\end{tabular}
    491498\hfil
     
    502509
    503510\begin{rationale}
    504 The use of ``\lstinline@?@'' in identifiers means that some C programs are not \CFA programs.  For instance, the sequence of characters ``\lstinline@(i < 0)?--i:i@'' is legal in a C program, but a
    505 \CFA compiler detects a syntax error because it treats ``\lstinline@?--@'' as an identifier, not as the two tokens ``\lstinline@?@'' and ``\lstinline@--@''.
     511The use of ``©?©'' in identifiers means that some C programs are not \CFA programs.  For instance, the sequence of characters ``©(i < 0)?--i:i©'' is legal in a C program, but a
     512\CFA compiler detects a syntax error because it treats ``©?--©'' as an identifier, not as the two tokens ``©?©'' and ``©--©''.
    506513\end{rationale}
    507514
     
    510517\begin{itemize}
    511518\item
    512 The logical operators ``\lstinline@&&@'' and ``\lstinline@||@'', and the conditional operator
    513 ``\lstinline@?:@''.
     519The logical operators ``©&&©'' and ``©||©'', and the conditional operator ``©?:©''.
    514520These operators do not always evaluate their operands, and hence can not be properly defined by functions unless some mechanism like call-by-name is added to the language.
    515 Note that the definitions of ``\lstinline@&&@'' and ``\lstinline@||@'' say that they work by checking that their arguments are unequal to 0, so defining ``\lstinline@!=@'' and ``\lstinline@0@'' for user-defined types is enough to allow them to be used in logical expressions.
     521Note that the definitions of ``©&&©'' and ``©||©'' say that they work by checking that their arguments are unequal to 0, so defining ``©!=©'' and ``©0©'' for user-defined types is enough to allow them to be used in logical expressions.
    516522
    517523\item
     
    522528\item
    523529The ``address of'' operator.
    524 It would seem useful to define a unary ``\lstinline@&@'' operator that returns values of some programmer-defined pointer-like type.
     530It would seem useful to define a unary ``©&©'' operator that returns values of some programmer-defined pointer-like type.
    525531The problem lies with the type of the operator.
    526 Consider the expression ``\lstinline@p = &x@'', where \lstinline@x@ is of type
    527 \lstinline@T@ and \lstinline@p@ has the programmer-defined type \lstinline@T_ptr@.
    528 The expression might be treated as a call to the unary function ``\lstinline@&?@''.
    529 Now what is the type of the function's parameter? It can not be \lstinline@T@, because then \lstinline@x@ would be passed by value, and there is no way to create a useful pointer-like result from a value.
    530 Hence the parameter must have type \lstinline@T *@.
    531 But then the expression must be rewritten as ``\lstinline@p = &?( &x )@''
     532Consider the expression ``©p = &x©'', where ©x© is of type ©T© and ©p© has the programmer-defined type ©T_ptr©.
     533The expression might be treated as a call to the unary function ``©&?©''.
     534Now what is the type of the function's parameter? It can not be ©T©, because then ©x© would be passed by value, and there is no way to create a useful pointer-like result from a value.
     535Hence the parameter must have type ©T *©.
     536But then the expression must be rewritten as ``©p = &?( &x )©''
    532537---which doesn't seem like progress!
    533538
    534539The rule for address-of expressions would have to be something like ``keep applying address-of functions until you get one that takes a pointer argument, then use the built-in operator and stop''.
    535 It seems simpler to define a conversion function from \lstinline@T *@ to \lstinline@T_ptr@.
    536 
    537 \item
    538 The \lstinline@sizeof@ operator.
     540It seems simpler to define a conversion function from ©T *© to ©T_ptr©.
     541
     542\item
     543The ©sizeof© operator.
    539544It is already defined for every object type, and intimately tied into the language's storage allocation model.
    540545Redefining it seems pointless.
    541546
    542547\item
    543 The ``member of'' operators ``\lstinline@.@'' and ``\lstinline@->@''.
     548The ``member of'' operators ``©.©'' and ``©->©''.
    544549These are not really infix operators, since their right ``operand'' is not a value or object.
    545550
     
    578583The ``fewest unsafe conversions'' rule ensures that the usual conversions are done, if possible.
    579584The ``lowest total expression cost'' rule chooses the proper common type.
    580 The odd-looking ``highest argument conversion cost'' rule ensures that, when unary expressions must be converted, conversions of function results are preferred to conversion of function arguments: \lstinline@(double)-i@ will be preferred to \lstinline@-(double)i@.
     585The odd-looking ``highest argument conversion cost'' rule ensures that, when unary expressions must be converted, conversions of function results are preferred to conversion of function arguments: ©(double)-i© will be preferred to ©-(double)i©.
    581586
    582587The ``least polymorphic'' rule reduces the number of polymorphic function calls, since such functions are presumably more expensive than monomorphic functions and since the more specific function is presumably more appropriate.
    583 It also gives preference to monomorphic values (such as the
    584 \lstinline@int@ \lstinline@0@) over polymorphic values (such as the \Index{null pointer}
    585 \lstinline@0@\use{0}).
     588It also gives preference to monomorphic values (such as the ©int© ©0©) over polymorphic values (such as the \Index{null pointer} ©0©\use{0}).
    586589However, interpretations that call polymorphic functions are preferred to interpretations that perform unsafe conversions, because those conversions potentially lose accuracy or violate strong typing.
    587590
     
    603606\begin{rationale}
    604607Predefined functions and constants have internal linkage because that simplifies optimization in traditional compile-and-link environments.
    605 For instance, ``\lstinline@an_int + an_int@'' is equivalent to ``\lstinline@?+?(an_int, an_int)@''.
     608For instance, ``©an_int + an_int©'' is equivalent to ``©?+?(an_int, an_int)©''.
    606609If integer addition has not been redefined in the current scope, a compiler can generate code to perform the addition directly.
    607610If predefined functions had external linkage, this optimization would be difficult.
     
    629632\rhs \nonterm{constant}
    630633\rhs \nonterm{string-literal}
    631 \rhs \lstinline@(@ \nonterm{expression} \lstinline@)@
     634\rhs ©(© \nonterm{expression} ©)©
    632635\rhs \nonterm{generic-selection}
    633636\end{syntax}
     
    645648
    646649A \nonterm{constant} or \nonterm{string-literal} has one valid interpretation, which has the type and value defined by {\c11}.
    647 The predefined integer identifiers ``\lstinline@1@'' and ``\lstinline@0@'' have the integer values 1 and 0, respectively.
    648 The other two predefined ``\lstinline@0@'' identifiers are bound to polymorphic pointer values that, when specialized\index{specialization} with a data type or function type respectively, produce a null pointer of that type.
     650The predefined integer identifiers ``©1©'' and ``©0©'' have the integer values 1 and 0, respectively.
     651The other two predefined ``©0©'' identifiers are bound to polymorphic pointer values that, when specialized\index{specialization} with a data type or function type respectively, produce a null pointer of that type.
    649652
    650653A parenthesised expression has the same interpretations as the contained \nonterm{expression}.
    651654
    652655\examples
    653 The expression \lstinline@(void *)0@\use{0} specializes the (polymorphic) null pointer to a null pointer to \lstinline@void@. \lstinline@(const void *)0@ does the same, and also uses a safe conversion from \lstinline@void *@ to \lstinline@const void *@.
    654 In each case, the null pointer conversion is better\index{best valid interpretations} than the unsafe conversion of the integer
    655 \lstinline@0@ to a pointer.
     656The expression ©(void *)0©\use{0} specializes the (polymorphic) null pointer to a null pointer to ©void©. ©(const void *)0© does the same, and also uses a safe conversion from ©void *© to ©const void *©.
     657In each case, the null pointer conversion is better\index{best valid interpretations} than the unsafe conversion of the integer ©0© to a pointer.
    656658
    657659\begin{rationale}
     
    659661
    660662\CFA does not have C's concept of ``null pointer constants'', which are not typed values but special strings of tokens.
    661 The C token ``\lstinline@0@'' is an expression of type \lstinline@int@ with the value ``zero'', and it \emph{also} is a null pointer constant.
    662 Similarly,
    663 ``\lstinline@(void *)0@ is an expression of type \lstinline@(void *)@ whose value is a null pointer, and it also is a null pointer constant.
    664 However, in C, ``\lstinline@(void *)(void *)0@'' is
     663The C token ``©0©'' is an expression of type ©int© with the value ``zero'', and it \emph{also} is a null pointer constant.
     664Similarly, ``©(void *)0© is an expression of type ©(void *)© whose value is a null pointer, and it also is a null pointer constant.
     665However, in C, ``©(void *)(void *)0©'' is
    665666\emph{not} a null pointer constant, even though it is null-valued, a pointer, and constant! The semantics of C expressions contain many special cases to deal with subexpressions that are null pointer constants.
    666667
     
    669670\begin{lstlisting}
    670671forall( dtype DT ) DT * const 0;
    671 \end{lstlisting} means that \lstinline@0@ is a polymorphic object, and contains a value that can have \emph{any} pointer-to-object type or pointer-to-incomplete type.
     672\end{lstlisting} means that ©0© is a polymorphic object, and contains a value that can have \emph{any} pointer-to-object type or pointer-to-incomplete type.
    672673The only such value is the null pointer.
    673674Therefore the type \emph{alone} is enough to identify a null pointer.
     
    679680
    680681\constraints The best interpretation of the controlling expression shall be unambiguous\index{ambiguous interpretation}, and shall have type compatible with at most one of the types named in its generic association list.
    681 If a generic selection has no \lstinline@default@ generic association, the best interpretation of its controlling expression shall have type compatible with exactly one of the types named in its generic association list.
     682If a generic selection has no ©default© generic association, the best interpretation of its controlling expression shall have type compatible with exactly one of the types named in its generic association list.
    682683
    683684\semantics
     
    690691\lhs{postfix-expression}
    691692\rhs \nonterm{primary-expression}
    692 \rhs \nonterm{postfix-expression} \lstinline@[@ \nonterm{expression} \lstinline@]@
    693 \rhs \nonterm{postfix-expression} \lstinline@(@
    694          \nonterm{argument-expression-list}\opt \lstinline@)@
    695 \rhs \nonterm{postfix-expression} \lstinline@.@ \nonterm{identifier}
    696 \rhs \nonterm{postfix-expression} \lstinline@->@ \nonterm{identifier}
    697 \rhs \nonterm{postfix-expression} \lstinline@++@
    698 \rhs \nonterm{postfix-expression} \lstinline@--@
    699 \rhs \lstinline@(@ \nonterm{type-name} \lstinline@)@ \lstinline@{@ \nonterm{initializer-list} \lstinline@}@
    700 \rhs \lstinline@(@ \nonterm{type-name} \lstinline@)@ \lstinline@{@ \nonterm{initializer-list} \lstinline@,@ \lstinline@}@
     693\rhs \nonterm{postfix-expression} ©[© \nonterm{expression} ©]©
     694\rhs \nonterm{postfix-expression} ©(©
     695         \nonterm{argument-expression-list}\opt ©)©
     696\rhs \nonterm{postfix-expression} ©.© \nonterm{identifier}
     697\rhs \nonterm{postfix-expression} ©->© \nonterm{identifier}
     698\rhs \nonterm{postfix-expression} ©++©
     699\rhs \nonterm{postfix-expression} ©--©
     700\rhs ©(© \nonterm{type-name} ©)© ©{© \nonterm{initializer-list} ©}©
     701\rhs ©(© \nonterm{type-name} ©)© ©{© \nonterm{initializer-list} ©,© ©}©
    701702\lhs{argument-expression-list}
    702703\rhs \nonterm{assignment-expression}
    703 \rhs \nonterm{argument-expression-list} \lstinline@,@
     704\rhs \nonterm{argument-expression-list} ©,©
    704705         \nonterm{assignment-expression}
    705706\end{syntax}
     
    739740The interpretations of subscript expressions are the interpretations of the corresponding function call expressions.
    740741\begin{rationale}
    741 C defines subscripting as pointer arithmetic in a way that makes \lstinline@a[i]@ and
    742 \lstinline@i[a]@ equivalent. \CFA provides the equivalence through a rewrite rule to reduce the number of overloadings of \lstinline@?[?]@.
     742C defines subscripting as pointer arithmetic in a way that makes ©a[i]© and ©i[a]© equivalent. \CFA provides the equivalence through a rewrite rule to reduce the number of overloadings of ©?[?]©.
    743743
    744744Subscript expressions are rewritten as function calls that pass the first parameter by value.
    745745This is somewhat unfortunate, since array-like types tend to be large.
    746 The alternative is to use the rewrite rule ``\lstinline@a[b]@ \rewrite \lstinline@?[?](&(a), b)@''.
    747 However, C semantics forbid this approach: the \lstinline@a@ in ``\lstinline@a[b]@'' can be an arbitrary pointer value, which does not have an address.
     746The alternative is to use the rewrite rule ``©a[b]© \rewrite ©?[?](&(a), b)©''.
     747However, C semantics forbid this approach: the ©a© in ``©a[b]©'' can be an arbitrary pointer value, which does not have an address.
    748748
    749749The repetitive form of the predefined identifiers shows up a deficiency\index{deficiencies!pointers
     
    760760\nonterm{postfix-expression} in a function call may have some interpretations that are function designators and some that are not.
    761761
    762 For those interpretations of the \nonterm{postfix-expression} that are not function designators, the expression is rewritten and becomes a call of a function named ``\lstinline@?()@''.
     762For those interpretations of the \nonterm{postfix-expression} that are not function designators, the expression is rewritten and becomes a call of a function named ``©?()©''.
    763763The valid interpretations of the rewritten expression are determined in the manner described below.
    764764
     
    767767\begin{itemize}
    768768\item if the argument corresponds to a parameter in the function designator's prototype, the argument interpretation must have the same type as the corresponding parameter, or be implicitly convertible to the parameter's type
    769 \item if the function designator's type does not include a prototype or if the argument corresponds to
    770 ``\lstinline@...@'' in a prototype, a \Index{default argument promotion} is applied to it.
     769\item if the function designator's type does not include a prototype or if the argument corresponds to ``©...©'' in a prototype, a \Index{default argument promotion} is applied to it.
    771770\end{itemize}
    772771The type of the valid interpretation is the return type of the function designator.
     
    776775\begin{itemize}
    777776\item
    778 If the declaration of the implicit parameter uses \Index{type-class} \lstinline@type@\use{type}, the implicit argument must be an object type;
    779 if it uses \lstinline@dtype@, the implicit argument must be an object type or an incomplete type;
    780 and if it uses \lstinline@ftype@, the implicit argument must be a function type.
     777If the declaration of the implicit parameter uses \Index{type-class} ©type©\use{type}, the implicit argument must be an object type;
     778if it uses ©dtype©, the implicit argument must be an object type or an incomplete type;
     779and if it uses ©ftype©, the implicit argument must be a function type.
    781780
    782781\item if an explicit parameter's type uses any implicit parameters, then the corresponding explicit argument must have a type that is (or can be safely converted\index{safe conversion} to) the type produced by substituting the implicit arguments for the implicit parameters in the explicit parameter type.
     
    797796\begin{rationale}
    798797One desirable property of a polymorphic programming language is \define{generalizability}: the ability to replace an abstraction with a more general but equivalent abstraction without requiring changes in any of the uses of the original\cite{Cormack90}.
    799 For instance, it should be possible to replace a function ``\lstinline@int f( int );@'' with ``\lstinline@forall( otype T ) T f( T );@'' without affecting any calls of \lstinline@f@.
     798For instance, it should be possible to replace a function ``©int f( int );©'' with ``©forall( otype T ) T f( T );©'' without affecting any calls of ©f©.
    800799
    801800\CFA\index{deficiencies!generalizability} does not fully possess this property, because
     
    811810f = g( d, f );          // (3) (unsafe conversion to float)
    812811\end{lstlisting}
    813 If \lstinline@g@ was replaced by ``\lstinline@forall( otype T ) T g( T, T );@'', the first and second calls would be unaffected, but the third would change: \lstinline@f@ would be converted to
    814 \lstinline@double@, and the result would be a \lstinline@double@.
    815 
    816 Another example is the function ``\lstinline@void h( int *);@''.
    817 This function can be passed a
    818 \lstinline@void *@ argument, but the generalization ``\lstinline@forall( otype T ) void h( T *);@'' can not.
    819 In this case, \lstinline@void@ is not a valid value for \lstinline@T@ because it is not an object type.
    820 If unsafe conversions were allowed, \lstinline@T@ could be inferred to be \emph{any} object type, which is undesirable.
     812If ©g© was replaced by ``©forall( otype T ) T g( T, T );©'', the first and second calls would be unaffected, but the third would change: ©f© would be converted to ©double©, and the result would be a ©double©.
     813
     814Another example is the function ``©void h( int *);©''.
     815This function can be passed a ©void *© argument, but the generalization ``©forall( otype T ) void h( T *);©'' can not.
     816In this case, ©void© is not a valid value for ©T© because it is not an object type.
     817If unsafe conversions were allowed, ©T© could be inferred to be \emph{any} object type, which is undesirable.
    821818\end{rationale}
    822819
    823820\examples
    824 A function called ``\lstinline@?()@'' might be part of a numerical differentiation package.
     821A function called ``©?()©'' might be part of a numerical differentiation package.
    825822\begin{lstlisting}
    826823extern otype Derivative;
     
    833830d = sin_dx( 12.9 );
    834831\end{lstlisting}
    835 Here, the only interpretation of \lstinline@sin_dx@ is as an object of type \lstinline@Derivative@.
    836 For that interpretation, the function call is treated as ``\lstinline@?()( sin_dx, 12.9 )@''.
     832Here, the only interpretation of ©sin_dx© is as an object of type ©Derivative©.
     833For that interpretation, the function call is treated as ``©?()( sin_dx, 12.9 )©''.
    837834\begin{lstlisting}
    838835int f( long );          // (1)
     
    841838int i = f( 5 );         // calls (1)
    842839\end{lstlisting}
    843 Function (1) provides a valid interpretation of ``\lstinline@f( 5 )@'', using an implicit \lstinline@int@ to \lstinline@long@ conversion.
    844 The other functions do not, since the second requires two arguments, and since there is no implicit conversion from \lstinline@int@ to \lstinline@int *@ that could be used with the third function.
     840Function (1) provides a valid interpretation of ``©f( 5 )©'', using an implicit ©int© to ©long© conversion.
     841The other functions do not, since the second requires two arguments, and since there is no implicit conversion from ©int© to ©int *© that could be used with the third function.
    845842
    846843\begin{lstlisting}
     
    848845double d = h( 1.5 );
    849846\end{lstlisting}
    850 ``\lstinline@1.5@'' is a \lstinline@double@ constant, so \lstinline@T@ is inferred to be
    851 \lstinline@double@, and the result of the function call is a \lstinline@double@.
     847``©1.5©'' is a ©double© constant, so ©T© is inferred to be ©double©, and the result of the function call is a ©double©.
    852848
    853849\begin{lstlisting}
    854850forall( otype T, otype U ) void g( T, U );      // (4)
    855851forall( otype T ) void g( T, T );                       // (5)
    856 forall( otype T ) void g( T, long );                    // (6)
     852forall( otype T ) void g( T, long );            // (6)
    857853void g( long, long );                                           // (7)
    858854double d;
    859855int i;
    860856int *p;
    861 g( d, d );                      // calls (5)
    862 g( d, i );                      // calls (6)
    863 g( i, i );                      // calls (7)
    864 g( i, p );                      // calls (4)
    865 \end{lstlisting}
    866 The first call has valid interpretations for all four versions of \lstinline@g@. (6) and (7) are discarded because they involve unsafe \lstinline@double@-to-\lstinline@long@ conversions. (5) is chosen because it is less polymorphic than (4).
     857g( d, d );                                                                      // calls (5)
     858g( d, i );                                                                      // calls (6)
     859g( i, i );                                                                      // calls (7)
     860g( i, p );                                                                      // calls (4)
     861\end{lstlisting}
     862The first call has valid interpretations for all four versions of ©g©. (6) and (7) are discarded because they involve unsafe ©double©-to-©long© conversions. (5) is chosen because it is less polymorphic than (4).
    867863
    868864For the second call, (7) is again discarded.
    869 Of the remaining interpretations for (4), (5), and (6) (with \lstinline@i@ converted to \lstinline@long@), (6) is chosen because it is the least polymorphic.
     865Of the remaining interpretations for (4), (5), and (6) (with ©i© converted to ©long©), (6) is chosen because it is the least polymorphic.
    870866
    871867The third call has valid interpretations for all of the functions;
     
    883879shuffle( 9, 10 );
    884880\end{lstlisting}
    885 The only possibility for \lstinline@U@ is \lstinline@double@, because that is the type used in the only visible \lstinline@max@ function. 9 and 10 must be converted to \lstinline@double@, and
    886 \lstinline@min@ must be specialized with \lstinline@T@ bound to \lstinline@double@.
    887 \begin{lstlisting}
    888 extern void q( int );           // (8)
    889 extern void q( void * );        // (9)
     881The only possibility for ©U© is ©double©, because that is the type used in the only visible ©max© function. 9 and 10 must be converted to ©double©, and ©min© must be specialized with ©T© bound to ©double©.
     882\begin{lstlisting}
     883extern void q( int );                                           // (8)
     884extern void q( void * );                                        // (9)
    890885extern void r();
    891886q( 0 );
    892887r( 0 );
    893888\end{lstlisting}
    894 The \lstinline@int 0@ could be passed to (8), or the \lstinline@(void *)@ \Index{specialization} of the null pointer\index{null pointer} \lstinline@0@\use{0} could be passed to (9).
    895 The former is chosen because the \lstinline@int@ \lstinline@0@ is \Index{less polymorphic}.
    896 For the same reason, \lstinline@int@ \lstinline@0@ is passed to \lstinline@r()@, even though it has \emph{no} declared parameter types.
     889The ©int 0© could be passed to (8), or the ©(void *)© \Index{specialization} of the null pointer\index{null pointer} ©0©\use{0} could be passed to (9).
     890The former is chosen because the ©int© ©0© is \Index{less polymorphic}.
     891For the same reason, ©int© ©0© is passed to ©r()©, even though it has \emph{no} declared parameter types.
    897892
    898893
    899894\subsubsection{Structure and union members}
    900895
    901 \semantics In the member selection expression ``\lstinline@s@.\lstinline@m@'', there shall be at least one interpretation of \lstinline@s@ whose type is a structure type or union type containing a member named \lstinline@m@.
    902 If two or more interpretations of \lstinline@s@ have members named
    903 \lstinline@m@ with mutually compatible types, then the expression has an \Index{ambiguous interpretation} whose type is the composite type of the types of the members.
    904 If an interpretation of \lstinline@s@ has a member \lstinline@m@ whose type is not compatible with any other
    905 \lstinline@s@'s \lstinline@m@, then the expression has an interpretation with the member's type.
     896\semantics In the member selection expression ``©s©.©m©'', there shall be at least one interpretation of ©s© whose type is a structure type or union type containing a member named ©m©.
     897If two or more interpretations of ©s© have members named ©m© with mutually compatible types, then the expression has an \Index{ambiguous interpretation} whose type is the composite type of the types of the members.
     898If an interpretation of ©s© has a member ©m© whose type is not compatible with any other ©s©'s ©m©, then the expression has an interpretation with the member's type.
    906899The expression has no other interpretations.
    907900
    908 The expression ``\lstinline@p->m@'' has the same interpretations as the expression ``\lstinline@(*p).m@''.
     901The expression ``©p->m©'' has the same interpretations as the expression ``©(*p).m©''.
    909902
    910903
     
    1001994        * ?--( _Atomic const restrict volatile T * _Atomic restrict volatile * );
    1002995\end{lstlisting}
    1003 For every extended integer type \lstinline@X@ there exist
     996For every extended integer type ©X© there exist
    1004997% Don't use predefined: keep this out of prelude.cf.
    1005998\begin{lstlisting}
     
    10071000  ?--( volatile X * ), ?--( _Atomic volatile X * );
    10081001\end{lstlisting}
    1009 For every complete enumerated type \lstinline@E@ there exist
     1002For every complete enumerated type ©E© there exist
    10101003% Don't use predefined: keep this out of prelude.cf.
    10111004\begin{lstlisting}
     
    10151008
    10161009\begin{rationale}
    1017 Note that ``\lstinline@++@'' and ``\lstinline@--@'' are rewritten as function calls that are given a pointer to that operand. (This is true of all operators that modify an operand.) As Hamish Macdonald has pointed out, this forces the modified operand of such expressions to be an lvalue.
     1010Note that ``©++©'' and ``©--©'' are rewritten as function calls that are given a pointer to that operand. (This is true of all operators that modify an operand.) As Hamish Macdonald has pointed out, this forces the modified operand of such expressions to be an lvalue.
    10181011This partially enforces the C semantic rule that such operands must be \emph{modifiable} lvalues.
    10191012\end{rationale}
     
    10211014\begin{rationale}
    10221015In C, a semantic rule requires that pointer operands of increment and decrement be pointers to object types.
    1023 Hence, \lstinline@void *@ objects cannot be incremented.
    1024 In \CFA, the restriction follows from the use of a \lstinline@type@ parameter in the predefined function definitions, as opposed to \lstinline@dtype@, since only object types can be inferred arguments corresponding to the type parameter \lstinline@T@.
     1016Hence, ©void *© objects cannot be incremented.
     1017In \CFA, the restriction follows from the use of a ©type© parameter in the predefined function definitions, as opposed to ©dtype©, since only object types can be inferred arguments corresponding to the type parameter ©T©.
    10251018\end{rationale}
    10261019
     
    10401033\end{lstlisting}
    10411034\begin{sloppypar}
    1042 Since \lstinline@&(vs)@ has type \lstinline@volatile short int *@, the best valid interpretation of
    1043 \lstinline@vs++@ calls the \lstinline@?++@ function with the \lstinline@volatile short *@ parameter.
    1044 \lstinline@s++@ does the same, applying the safe conversion from \lstinline@short int *@ to \lstinline@volatile short int *@.
    1045 Note that there is no conversion that adds an \lstinline@_Atomic@ qualifier, so the \lstinline@_Atomic volatile short int@ overloading does not provide a valid interpretation.
     1035Since ©&(vs)© has type ©volatile short int *©, the best valid interpretation of ©vs++© calls the ©?++© function with the ©volatile short *© parameter.
     1036©s++© does the same, applying the safe conversion from ©short int *© to ©volatile short int *©.
     1037Note that there is no conversion that adds an ©_Atomic© qualifier, so the ©_Atomic volatile short int© overloading does not provide a valid interpretation.
    10461038\end{sloppypar}
    10471039
    1048 There is no safe conversion from \lstinline@const short int *@ to \lstinline@volatile short int *@, and no \lstinline@?++@ function that accepts a \lstinline@const *@ parameter, so \lstinline@cs++@ has no valid interpretations.
    1049 
    1050 The best valid interpretation of \lstinline@as++@ calls the \lstinline@short ?++@ function with the \lstinline@_Atomic volatile short int *@ parameter, applying a safe conversion to add the \lstinline@volatile@ qualifier.
     1040There is no safe conversion from ©const short int *© to ©volatile short int *©, and no ©?++© function that accepts a ©const *© parameter, so ©cs++© has no valid interpretations.
     1041
     1042The best valid interpretation of ©as++© calls the ©short ?++© function with the ©_Atomic volatile short int *© parameter, applying a safe conversion to add the ©volatile© qualifier.
    10511043\begin{lstlisting}
    10521044char * const restrict volatile * restrict volatile pqpc;
     
    10551047ppc++;
    10561048\end{lstlisting}
    1057 Since \lstinline@&(pqpc)@ has type \lstinline@char * const restrict volatile * restrict volatile *@, the best valid interpretation of \lstinline@pqpc++@ calls the polymorphic \lstinline@?++@ function with the \lstinline@const restrict volatile T * restrict volatile *@ parameter, inferring \lstinline@T@ to be \lstinline@char *@.
    1058 
    1059 \lstinline@ppc++@ calls the same function, again inferring \lstinline@T@ to be \lstinline@char *@, and using the safe conversions from \lstinline@T@ to \lstinline@T const@ \lstinline@restrict volatile@.
     1049Since ©&(pqpc)© has type ©char * const restrict volatile * restrict volatile *©, the best valid interpretation of ©pqpc++© calls the polymorphic ©?++© function with the ©const restrict volatile T * restrict volatile *© parameter, inferring ©T© to be ©char *©.
     1050
     1051©ppc++© calls the same function, again inferring ©T© to be ©char *©, and using the safe conversions from ©T© to ©T const© ©restrict volatile©.
    10601052
    10611053\begin{rationale}
     
    10711063\begin{enumerate}
    10721064\item
    1073 ``\lstinline@char * p; p++;@''.
    1074 The argument to \lstinline@?++@ has type \lstinline@char * *@, and the result has type \lstinline@char *@.
    1075 The expression would be valid if \lstinline@?++@ were declared by
     1065``©char * p; p++;©''.
     1066The argument to ©?++© has type ©char * *©, and the result has type ©char *©.
     1067The expression would be valid if ©?++© were declared by
    10761068\begin{lstlisting}
    10771069forall( otype T ) T * ?++( T * * );
    1078 \end{lstlisting} with \lstinline@T@ inferred to be \lstinline@char@.
    1079 
    1080 \item
    1081 ``\lstinline@char *restrict volatile qp; qp++@''.
    1082 The result again has type \lstinline@char *@, but the argument now has type \lstinline@char *restrict volatile *@, so it cannot be passed to the hypothetical function declared in point 1.
     1070\end{lstlisting} with ©T© inferred to be ©char©.
     1071
     1072\item
     1073``©char *restrict volatile qp; qp++©''.
     1074The result again has type ©char *©, but the argument now has type ©char *restrict volatile *©, so it cannot be passed to the hypothetical function declared in point 1.
    10831075Hence the actual predefined function is
    10841076\begin{lstlisting}
    10851077forall( otype T ) T * ?++( T * restrict volatile * );
    1086 \end{lstlisting} which also accepts a \lstinline@char * *@ argument, because of the safe conversions that add
    1087 \lstinline@volatile@ and \lstinline@restrict@ qualifiers. (The parameter is not const-qualified, so constant pointers cannot be incremented.)
    1088 
    1089 \item
    1090 ``\lstinline@char *_Atomic ap; ap++@''.
    1091 The result again has type \lstinline@char *@, but no safe conversion adds an \lstinline@_Atomic@ qualifier, so the function in point 2 is not applicable.
    1092 A separate overloading of \lstinline@?++@ is required.
    1093 
    1094 \item
    1095 ``\lstinline@char const volatile * pq; pq++@''.
    1096 Here the result has type
    1097 \lstinline@char const volatile *@, so a new overloading is needed:
     1078\end{lstlisting} which also accepts a ©char * *© argument, because of the safe conversions that add ©volatile© and ©restrict© qualifiers. (The parameter is not const-qualified, so constant pointers cannot be incremented.)
     1079
     1080\item
     1081``©char *_Atomic ap; ap++©''.
     1082The result again has type ©char *©, but no safe conversion adds an ©_Atomic© qualifier, so the function in point 2 is not applicable.
     1083A separate overloading of ©?++© is required.
     1084
     1085\item
     1086``©char const volatile * pq; pq++©''.
     1087Here the result has type ©char const volatile *©, so a new overloading is needed:
    10981088\begin{lstlisting}
    10991089forall( otype T ) T const volatile * ?++( T const volatile *restrict volatile * );
     
    11021092 
    11031093\item
    1104 ``\lstinline@float *restrict * prp; prp++@''.
    1105 The \lstinline@restrict@ qualifier is handled just like \lstinline@const@ and \lstinline@volatile@ in the previous case:
     1094``©float *restrict * prp; prp++©''.
     1095The ©restrict© qualifier is handled just like ©const© and ©volatile© in the previous case:
    11061096\begin{lstlisting}
    11071097forall( otype T ) T restrict * ?++( T restrict *restrict volatile * );
    1108 \end{lstlisting} with \lstinline@T@ inferred to be \lstinline@float *@.
    1109 This looks odd, because {\c11} contains a constraint that requires restrict-qualified types to be pointer-to-object types, and \lstinline@T@ is not syntactically a pointer type. \CFA loosens the constraint.
     1098\end{lstlisting} with ©T© inferred to be ©float *©.
     1099This looks odd, because {\c11} contains a constraint that requires restrict-qualified types to be pointer-to-object types, and ©T© is not syntactically a pointer type. \CFA loosens the constraint.
    11101100\end{enumerate}
    11111101\end{rationale}
     
    11231113\lhs{unary-expression}
    11241114\rhs \nonterm{postfix-expression}
    1125 \rhs \lstinline@++@ \nonterm{unary-expression}
    1126 \rhs \lstinline@--@ \nonterm{unary-expression}
     1115\rhs ©++© \nonterm{unary-expression}
     1116\rhs ©--© \nonterm{unary-expression}
    11271117\rhs \nonterm{unary-operator} \nonterm{cast-expression}
    1128 \rhs \lstinline@sizeof@ \nonterm{unary-expression}
    1129 \rhs \lstinline@sizeof@ \lstinline@(@ \nonterm{type-name} \lstinline@)@
    1130 \lhs{unary-operator} one of \rhs \lstinline@&@ \lstinline@*@ \lstinline@+@ \lstinline@-@ \lstinline@~@ \lstinline@!@
     1118\rhs ©sizeof© \nonterm{unary-expression}
     1119\rhs ©sizeof© ©(© \nonterm{type-name} ©)©
     1120\lhs{unary-operator} one of \rhs ©&© ©*© ©+© ©-© ©~© ©!©
    11311121\end{syntax}
    11321122
     
    12351225        * --?( _Atomic const restrict volatile T * _Atomic restrict volatile * );
    12361226\end{lstlisting}
    1237 For every extended integer type \lstinline@X@ there exist
     1227For every extended integer type ©X© there exist
    12381228% Don't use predefined: keep this out of prelude.cf.
    12391229\begin{lstlisting}
     
    12431233        --?( _Atomic volatile X * );
    12441234\end{lstlisting}
    1245 For every complete enumerated type \lstinline@E@ there exist
     1235For every complete enumerated type ©E© there exist
    12461236% Don't use predefined: keep this out of prelude.cf.
    12471237\begin{lstlisting}
     
    12801270
    12811271\constraints
    1282 The operand of the unary ``\lstinline@&@'' operator shall have exactly one
     1272The operand of the unary ``©&©'' operator shall have exactly one
    12831273\Index{interpretation}\index{ambiguous interpretation}, which shall be unambiguous.
    12841274
    12851275\semantics
    1286 The ``\lstinline@&@'' expression has one interpretation which is of type \lstinline@T *@, where
    1287 \lstinline@T@ is the type of the operand.
     1276The ``©&©'' expression has one interpretation which is of type ©T *©, where ©T© is the type of the operand.
    12881277
    12891278The interpretations of an indirection expression are the interpretations of the corresponding function call.
     
    13141303forall( ftype FT ) int !?( FT * );
    13151304\end{lstlisting}
    1316 For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
     1305For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist
    13171306% Don't use predefined: keep this out of prelude.cf.
    13181307\begin{lstlisting}
     
    13301319eat_double(-li ); // §\rewrite§ eat_double( -?( li ) );
    13311320\end{lstlisting}
    1332 The valid interpretations of ``\lstinline@-li@'' (assuming no extended integer types exist) are
     1321The valid interpretations of ``©-li©'' (assuming no extended integer types exist) are
    13331322\begin{center}
    13341323\begin{tabular}{llc} interpretation & result type & expression conversion cost \\
    13351324\hline
    1336 \lstinline@-?( (int)li )@                                       & \lstinline@int@                                       & (unsafe) \\
    1337 \lstinline@-?( (unsigned)li)@                           & \lstinline@unsigned int@                      & (unsafe) \\
    1338 \lstinline@-?( (long)li)@                                       & \lstinline@long@                                      & 0 \\
    1339 \lstinline@-?( (long unsigned int)li)@          & \lstinline@long unsigned int@         & 1 \\
    1340 \lstinline@-?( (long long int)li)@                      & \lstinline@long long int@                     & 2 \\
    1341 \lstinline@-?( (long long unsigned int)li)@     & \lstinline@long long unsigned int@& 3 \\
    1342 \lstinline@-?( (float)li)@                                      & \lstinline@float@                                     & 4 \\
    1343 \lstinline@-?( (double)li)@                                     & \lstinline@double@                            & 5 \\
    1344 \lstinline@-?( (long double)li)@                        & \lstinline@long double@                       & 6 \\
    1345 \lstinline@-?( (_Complex float)li)@                     & \lstinline@float@                                     & (unsafe) \\
    1346 \lstinline@-?( (_Complex double)li)@            & \lstinline@double@                            & (unsafe) \\
    1347 \lstinline@-?( (_Complex long double)li)@       & \lstinline@long double@                       & (unsafe) \\
     1325©-?( (int)li )©                                         & ©int©                                         & (unsafe) \\
     1326©-?( (unsigned)li)©                                     & ©unsigned int©                        & (unsafe) \\
     1327©-?( (long)li)©                                         & ©long©                                        & 0 \\
     1328©-?( (long unsigned int)li)©            & ©long unsigned int©           & 1 \\
     1329©-?( (long long int)li)©                        & ©long long int©                       & 2 \\
     1330©-?( (long long unsigned int)li)©       & ©long long unsigned int©      & 3 \\
     1331©-?( (float)li)©                                        & ©float©                                       & 4 \\
     1332©-?( (double)li)©                                       & ©double©                                      & 5 \\
     1333©-?( (long double)li)©                          & ©long double©                         & 6 \\
     1334©-?( (_Complex float)li)©                       & ©float©                                       & (unsafe) \\
     1335©-?( (_Complex double)li)©                      & ©double©                                      & (unsafe) \\
     1336©-?( (_Complex long double)li)©         & ©long double©                         & (unsafe) \\
    13481337\end{tabular}
    13491338\end{center}
    1350 The valid interpretations of the \lstinline@eat_double@ call, with the cost of the argument conversion and the cost of the entire expression, are
     1339The valid interpretations of the ©eat_double© call, with the cost of the argument conversion and the cost of the entire expression, are
    13511340\begin{center}
    13521341\begin{tabular}{lcc} interpretation & argument cost & expression cost \\
    13531342\hline
    1354 \lstinline@eat_double( (double)-?( (int)li) )@                                  & 7                     & (unsafe) \\
    1355 \lstinline@eat_double( (double)-?( (unsigned)li) )@                             & 6                     & (unsafe) \\
    1356 \lstinline@eat_double( (double)-?(li) )@                                                & 5                     & \(0+5=5\) \\
    1357 \lstinline@eat_double( (double)-?( (long unsigned int)li) )@    & 4                     & \(1+4=5\) \\
    1358 \lstinline@eat_double( (double)-?( (long long int)li) )@                & 3                     & \(2+3=5\) \\
    1359 \lstinline@eat_double( (double)-?( (long long unsigned int)li) )@& 2            & \(3+2=5\) \\
    1360 \lstinline@eat_double( (double)-?( (float)li) )@                                & 1                     & \(4+1=5\) \\
    1361 \lstinline@eat_double( (double)-?( (double)li) )@                               & 0                     & \(5+0=5\) \\
    1362 \lstinline@eat_double( (double)-?( (long double)li) )@                  & (unsafe)      & (unsafe) \\
    1363 \lstinline@eat_double( (double)-?( (_Complex float)li) )@               & (unsafe)      & (unsafe) \\
    1364 \lstinline@eat_double( (double)-?( (_Complex double)li) )@              & (unsafe)      & (unsafe) \\
    1365 \lstinline@eat_double( (double)-?( (_Complex long double)li) )@ & (unsafe)      & (unsafe) \\
     1343©eat_double( (double)-?( (int)li) )©                                    & 7                     & (unsafe) \\
     1344©eat_double( (double)-?( (unsigned)li) )©                               & 6                     & (unsafe) \\
     1345©eat_double( (double)-?(li) )©                                                  & 5                     & \(0+5=5\) \\
     1346©eat_double( (double)-?( (long unsigned int)li) )©              & 4                     & \(1+4=5\) \\
     1347©eat_double( (double)-?( (long long int)li) )©                  & 3                     & \(2+3=5\) \\
     1348©eat_double( (double)-?( (long long unsigned int)li) )© & 2                     & \(3+2=5\) \\
     1349©eat_double( (double)-?( (float)li) )©                                  & 1                     & \(4+1=5\) \\
     1350©eat_double( (double)-?( (double)li) )©                                 & 0                     & \(5+0=5\) \\
     1351©eat_double( (double)-?( (long double)li) )©                    & (unsafe)      & (unsafe) \\
     1352©eat_double( (double)-?( (_Complex float)li) )©                 & (unsafe)      & (unsafe) \\
     1353©eat_double( (double)-?( (_Complex double)li) )©                & (unsafe)      & (unsafe) \\
     1354©eat_double( (double)-?( (_Complex long double)li) )©   & (unsafe)      & (unsafe) \\
    13661355\end{tabular}
    13671356\end{center}
    1368 Each has result type \lstinline@void@, so the best must be selected.
     1357Each has result type ©void©, so the best must be selected.
    13691358The interpretations involving unsafe conversions are discarded.
    1370 The remainder have equal expression conversion costs, so the
    1371 ``highest argument conversion cost'' rule is invoked, and the chosen interpretation is
    1372 \lstinline@eat_double( (double)-?(li) )@.
     1359The remainder have equal expression conversion costs, so the ``highest argument conversion cost'' rule is invoked, and the chosen interpretation is ©eat_double( (double)-?(li) )©.
    13731360
    13741361
     
    13761363
    13771364\constraints
    1378 The operand of \lstinline@sizeof@ or \lstinline@_Alignof@ shall not be \lstinline@type@, \lstinline@dtype@, or \lstinline@ftype@.
    1379 
    1380 When the \lstinline@sizeof@\use{sizeof} operator is applied to an expression, the expression shall have exactly one \Index{interpretation}\index{ambiguous interpretation}, which shall be unambiguous. \semantics A \lstinline@sizeof@ or \lstinline@_Alignof@ expression has one interpretation, of type \lstinline@size_t@.
    1381 
    1382 When \lstinline@sizeof@ is applied to an identifier declared by a \nonterm{type-declaration} or a
     1365The operand of ©sizeof© or ©_Alignof© shall not be ©type©, ©dtype©, or ©ftype©.
     1366
     1367When the ©sizeof©\use{sizeof} operator is applied to an expression, the expression shall have exactly one \Index{interpretation}\index{ambiguous interpretation}, which shall be unambiguous. \semantics A ©sizeof© or ©_Alignof© expression has one interpretation, of type ©size_t©.
     1368
     1369When ©sizeof© is applied to an identifier declared by a \nonterm{type-declaration} or a
    13831370\nonterm{type-parameter}, it yields the size in bytes of the type that implements the operand.
    13841371When the operand is an opaque type or an inferred type parameter\index{inferred parameter}, the expression is not a constant expression.
    13851372
    1386 When \lstinline@_Alignof@ is applied to an identifier declared by a \nonterm{type-declaration} or a
     1373When ©_Alignof© is applied to an identifier declared by a \nonterm{type-declaration} or a
    13871374\nonterm{type-parameter}, it yields the alignment requirement of the type that implements the operand.
    13881375When the operand is an opaque type or an inferred type parameter\index{inferred parameter}, the expression is not a constant expression.
     
    13981385}
    13991386\end{lstlisting}
    1400 ``\lstinline@sizeof Rational@'', although not statically known, is fixed.
    1401 Within \lstinline@f()@,
    1402 ``\lstinline@sizeof(T)@'' is fixed for each call of \lstinline@f()@, but may vary from call to call.
     1387``©sizeof Rational©'', although not statically known, is fixed.
     1388Within ©f()©, ``©sizeof(T)©'' is fixed for each call of ©f()©, but may vary from call to call.
    14031389\end{rationale}
    14041390
     
    14091395\lhs{cast-expression}
    14101396\rhs \nonterm{unary-expression}
    1411 \rhs \lstinline@(@ \nonterm{type-name} \lstinline@)@ \nonterm{cast-expression}
     1397\rhs ©(© \nonterm{type-name} ©)© \nonterm{cast-expression}
    14121398\end{syntax}
    14131399
    14141400\constraints
    1415 The \nonterm{type-name} in a \nonterm{cast-expression} shall not be \lstinline@type@,
    1416 \lstinline@dtype@, or \lstinline@ftype@.
     1401The \nonterm{type-name} in a \nonterm{cast-expression} shall not be ©type©, ©dtype©, or ©ftype©.
    14171402
    14181403\semantics
    14191404
    1420 In a \Index{cast expression} ``\lstinline@(@\nonterm{type-name}\lstinline@)e@'', if
    1421 \nonterm{type-name} is the type of an interpretation of \lstinline@e@, then that interpretation is the only interpretation of the cast expression;
    1422 otherwise, \lstinline@e@ shall have some interpretation that can be converted to \nonterm{type-name}, and the interpretation of the cast expression is the cast of the interpretation that can be converted at the lowest cost.
     1405In a \Index{cast expression} ``©(©\nonterm{type-name}©)e©'', if
     1406\nonterm{type-name} is the type of an interpretation of ©e©, then that interpretation is the only interpretation of the cast expression;
     1407otherwise, ©e© shall have some interpretation that can be converted to \nonterm{type-name}, and the interpretation of the cast expression is the cast of the interpretation that can be converted at the lowest cost.
    14231408The cast expression's interpretation is ambiguous\index{ambiguous interpretation} if more than one interpretation can be converted at the lowest cost or if the selected interpretation is ambiguous.
    14241409
     
    14331418\lhs{multiplicative-expression}
    14341419\rhs \nonterm{cast-expression}
    1435 \rhs \nonterm{multiplicative-expression} \lstinline@*@ \nonterm{cast-expression}
    1436 \rhs \nonterm{multiplicative-expression} \lstinline@/@ \nonterm{cast-expression}
    1437 \rhs \nonterm{multiplicative-expression} \lstinline@%@ \nonterm{cast-expression}
     1420\rhs \nonterm{multiplicative-expression} ©*© \nonterm{cast-expression}
     1421\rhs \nonterm{multiplicative-expression} ©/© \nonterm{cast-expression}
     1422\rhs \nonterm{multiplicative-expression} ©%© \nonterm{cast-expression}
    14381423\end{syntax}
    14391424
     
    14691454        ?*?( _Complex long double, _Complex long double ), ?/?( _Complex long double, _Complex long double );
    14701455\end{lstlisting}
    1471 For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
     1456For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist
    14721457% Don't use predefined: keep this out of prelude.cf.
    14731458\begin{lstlisting}
     
    14901475eat_double( li % i );
    14911476\end{lstlisting}
    1492 ``\lstinline@li % i@'' is rewritten as ``\lstinline@?%?(li, i )@''.
    1493 The valid interpretations of \lstinline@?%?(li, i )@, the cost\index{conversion cost} of converting their arguments, and the cost of converting the result to \lstinline@double@ (assuming no extended integer types are present ) are
     1477``©li % i©'' is rewritten as ``©?%?(li, i )©''.
     1478The valid interpretations of ©?%?(li, i )©, the cost\index{conversion cost} of converting their arguments, and the cost of converting the result to ©double© (assuming no extended integer types are present ) are
    14941479\begin{center}
    14951480\begin{tabular}{lcc} interpretation & argument cost & result cost \\
    1496 \hline 
    1497 \lstinline@ ?%?( (int)li, i )@                                                                          & (unsafe)      & 6     \\
    1498 \lstinline@ ?%?( (unsigned)li,(unsigned)i )@                                            & (unsafe)      & 5     \\
    1499 \lstinline@ ?%?( li, (long)i )@                                                                         & 1                     & 4     \\
    1500 \lstinline@ ?%?( (long unsigned)li,(long unsigned)i )@                          & 3                     & 3     \\
    1501 \lstinline@ ?%?( (long long)li,(long long)i )@                                          & 5                     & 2     \\
    1502 \lstinline@ ?%?( (long long unsigned)li, (long long unsigned)i )@       & 7                     & 1     \\
     1481\hline
     1482© ?%?( (int)li, i )©                                                                            & (unsafe)      & 6     \\
     1483© ?%?( (unsigned)li,(unsigned)i )©                                                      & (unsafe)      & 5     \\
     1484© ?%?( li, (long)i )©                                                                           & 1                     & 4     \\
     1485© ?%?( (long unsigned)li,(long unsigned)i )©                            & 3                     & 3     \\
     1486© ?%?( (long long)li,(long long)i )©                                            & 5                     & 2     \\
     1487© ?%?( (long long unsigned)li, (long long unsigned)i )©         & 7                     & 1     \\
    15031488\end{tabular}
    15041489\end{center}
    1505 The best interpretation of \lstinline@eat_double( li, i )@ is
    1506 \lstinline@eat_double( (double)?%?(li, (long)i ))@, which has no unsafe conversions and the lowest total cost.
    1507 
    1508 \begin{rationale}
    1509 {\c11} defines most arithmetic operations to apply an \Index{integer promotion} to any argument that belongs to a type that has an \Index{integer conversion rank} less than that of \lstinline@int@.If
    1510 \lstinline@s@ is a \lstinline@short int@, ``\lstinline@s *s@'' does not have type \lstinline@short int@;
    1511 it is treated as ``\lstinline@( (int)s ) * ( (int)s )@'', and has type \lstinline@int@. \CFA matches that pattern;
    1512 it does not predefine ``\lstinline@short ?*?( short, short )@''.
     1490The best interpretation of ©eat_double( li, i )© is ©eat_double( (double)?%?(li, (long)i ))©, which has no unsafe conversions and the lowest total cost.
     1491
     1492\begin{rationale}
     1493{\c11} defines most arithmetic operations to apply an \Index{integer promotion} to any argument that belongs to a type that has an \Index{integer conversion rank} less than that of ©int©.
     1494If ©s© is a ©short int©, ``©s *s©'' does not have type ©short int©;
     1495it is treated as ``©( (int)s ) * ( (int)s )©'', and has type ©int©. \CFA matches that pattern;
     1496it does not predefine ``©short ?*?( short, short )©''.
    15131497
    15141498These ``missing'' operators limit polymorphism.
     
    15191503square( s );
    15201504\end{lstlisting}
    1521 Since \CFA does not define a multiplication operator for \lstinline@short int@,
    1522 \lstinline@square( s )@ is treated as \lstinline@square( (int)s )@, and the result has type
    1523 \lstinline@int@.
     1505Since \CFA does not define a multiplication operator for ©short int©, ©square( s )© is treated as ©square( (int)s )©, and the result has type ©int©.
    15241506This is mildly surprising, but it follows the {\c11} operator pattern.
    15251507
     
    15301512product( sa, 5);
    15311513\end{lstlisting}
    1532 This has no valid interpretations, because \CFA has no conversion from ``array of
    1533 \lstinline@short int@'' to ``array of \lstinline@int@''.
     1514This has no valid interpretations, because \CFA has no conversion from ``array of ©short int©'' to ``array of ©int©''.
    15341515The alternatives in such situations include
    15351516\begin{itemize}
    15361517\item
    1537 Defining monomorphic overloadings of \lstinline@product@ for \lstinline@short@ and the other
    1538 ``small'' types.
    1539 \item
    1540 Defining ``\lstinline@short ?*?( short, short )@'' within the scope containing the call to
    1541 \lstinline@product@.
    1542 \item
    1543 Defining \lstinline@product@ to take as an argument a conversion function from the ``small'' type to the operator's argument type.
     1518Defining monomorphic overloadings of ©product© for ©short© and the other ``small'' types.
     1519\item
     1520Defining ``©short ?*?( short, short )©'' within the scope containing the call to ©product©.
     1521\item
     1522Defining ©product© to take as an argument a conversion function from the ``small'' type to the operator's argument type.
    15441523\end{itemize}
    15451524\end{rationale}
     
    15511530\lhs{additive-expression}
    15521531\rhs \nonterm{multiplicative-expression}
    1553 \rhs \nonterm{additive-expression} \lstinline@+@ \nonterm{multiplicative-expression}
    1554 \rhs \nonterm{additive-expression} \lstinline@-@ \nonterm{multiplicative-expression}
     1532\rhs \nonterm{additive-expression} ©+© \nonterm{multiplicative-expression}
     1533\rhs \nonterm{additive-expression} ©-© \nonterm{multiplicative-expression}
    15551534\end{syntax}
    15561535
     
    16111590        * ?-?( _Atomic const restrict volatile T *, _Atomic const restrict volatile T * );
    16121591\end{lstlisting}
    1613 For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
     1592For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist
    16141593% Don't use predefined: keep this out of prelude.cf.
    16151594\begin{lstlisting}
     
    16211600
    16221601\begin{rationale}
    1623 \lstinline@ptrdiff_t@ is an implementation-defined identifier defined in \lstinline@<stddef.h>@ that is synonymous with a signed integral type that is large enough to hold the difference between two pointers.
     1602©ptrdiff_t© is an implementation-defined identifier defined in ©<stddef.h>© that is synonymous with a signed integral type that is large enough to hold the difference between two pointers.
    16241603It seems reasonable to use it for pointer addition as well. (This is technically a difference between \CFA and C, which only specifies that pointer addition uses an \emph{integral} argument.) Hence it is also used for subscripting, which is defined in terms of pointer addition.
    1625 The {\c11} standard uses \lstinline@size_t@ in several cases where a library function takes an argument that is used as a subscript, but \lstinline@size_t@ is unsuitable here because it is an unsigned type.
     1604The {\c11} standard uses ©size_t© in several cases where a library function takes an argument that is used as a subscript, but ©size_t© is unsuitable here because it is an unsigned type.
    16261605\end{rationale}
    16271606
     
    16321611\lhs{shift-expression}
    16331612\rhs \nonterm{additive-expression}
    1634 \rhs \nonterm{shift-expression} \lstinline@<<@ \nonterm{additive-expression}
    1635 \rhs \nonterm{shift-expression} \lstinline@>>@ \nonterm{additive-expression}
     1613\rhs \nonterm{shift-expression} ©<<© \nonterm{additive-expression}
     1614\rhs \nonterm{shift-expression} ©>>© \nonterm{additive-expression}
    16361615\end{syntax}
    16371616
     
    16511630long long unsigned int ?<<?( long long unsigned int, int ), ?>>?( long long unsigned int, int);
    16521631\end{lstlisting}
    1653 For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
     1632For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist
    16541633% Don't use predefined: keep this out of prelude.cf.
    16551634\begin{lstlisting}
     
    16711650\lhs{relational-expression}
    16721651\rhs \nonterm{shift-expression}
    1673 \rhs \nonterm{relational-expression} \lstinline@< @ \nonterm{shift-expression}
    1674 \rhs \nonterm{relational-expression} \lstinline@> @ \nonterm{shift-expression}
    1675 \rhs \nonterm{relational-expression} \lstinline@<=@ \nonterm{shift-expression}
    1676 \rhs \nonterm{relational-expression} \lstinline@>=@ \nonterm{shift-expression}
     1652\rhs \nonterm{relational-expression} ©< © \nonterm{shift-expression}
     1653\rhs \nonterm{relational-expression} ©> © \nonterm{shift-expression}
     1654\rhs \nonterm{relational-expression} ©<=© \nonterm{shift-expression}
     1655\rhs \nonterm{relational-expression} ©>=© \nonterm{shift-expression}
    16771656\end{syntax}
    16781657
     
    17141693        ?>=?( _Atomic const restrict volatile DT *, _Atomic const restrict volatile DT * );
    17151694\end{lstlisting}
    1716 For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
     1695For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist
    17171696% Don't use predefined: keep this out of prelude.cf.
    17181697\begin{lstlisting}
     
    17321711\lhs{equality-expression}
    17331712\rhs \nonterm{relational-expression}
    1734 \rhs \nonterm{equality-expression} \lstinline@==@ \nonterm{relational-expression}
    1735 \rhs \nonterm{equality-expression} \lstinline@!=@ \nonterm{relational-expression}
     1713\rhs \nonterm{equality-expression} ©==© \nonterm{relational-expression}
     1714\rhs \nonterm{equality-expression} ©!=© \nonterm{relational-expression}
    17361715\end{syntax}
    17371716
     
    17921771        ?==?( forall( ftype FT2) FT2*, forall( ftype FT3) FT3 * ), ?!=?( forall( ftype FT2) FT2*, forall( ftype FT3) FT3 * );
    17931772\end{lstlisting}
    1794 For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
     1773For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist
    17951774% Don't use predefined: keep this out of prelude.cf.
    17961775\begin{lstlisting}
     
    18001779
    18011780\begin{rationale}
    1802 The polymorphic equality operations come in three styles: comparisons between pointers of compatible types, between pointers to \lstinline@void@ and pointers to object types or incomplete types, and between the \Index{null pointer} constant and pointers to any type.
     1781The polymorphic equality operations come in three styles: comparisons between pointers of compatible types, between pointers to ©void© and pointers to object types or incomplete types, and between the \Index{null pointer} constant and pointers to any type.
    18031782In the last case, a special constraint rule for null pointer constant operands has been replaced by a consequence of the \CFA type system.
    18041783\end{rationale}
     
    18211800\lhs{AND-expression}
    18221801\rhs \nonterm{equality-expression}
    1823 \rhs \nonterm{AND-expression} \lstinline@&@ \nonterm{equality-expression}
     1802\rhs \nonterm{AND-expression} ©&© \nonterm{equality-expression}
    18241803\end{syntax}
    18251804
     
    18381817long long unsigned int ?&?( long long unsigned int, long long unsigned int );
    18391818\end{lstlisting}
    1840 For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
     1819For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist
    18411820% Don't use predefined: keep this out of prelude.cf.
    18421821\begin{lstlisting}
     
    18531832\lhs{exclusive-OR-expression}
    18541833\rhs \nonterm{AND-expression}
    1855 \rhs \nonterm{exclusive-OR-expression} \lstinline@^@ \nonterm{AND-expression}
     1834\rhs \nonterm{exclusive-OR-expression} ©^© \nonterm{AND-expression}
    18561835\end{syntax}
    18571836
     
    18701849long long unsigned int ?^?( long long unsigned int, long long unsigned int );
    18711850\end{lstlisting}
    1872 For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
     1851For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist
    18731852% Don't use predefined: keep this out of prelude.cf.
    18741853\begin{lstlisting}
     
    18851864\lhs{inclusive-OR-expression}
    18861865\rhs \nonterm{exclusive-OR-expression}
    1887 \rhs \nonterm{inclusive-OR-expression} \lstinline@|@ \nonterm{exclusive-OR-expression}
     1866\rhs \nonterm{inclusive-OR-expression} ©|© \nonterm{exclusive-OR-expression}
    18881867\end{syntax}
    18891868
     
    19021881long long unsigned int ?|?( long long unsigned int, long long unsigned int );
    19031882\end{lstlisting}
    1904 For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
     1883For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist
    19051884% Don't use predefined: keep this out of prelude.cf.
    19061885\begin{lstlisting}
     
    19171896\lhs{logical-AND-expression}
    19181897\rhs \nonterm{inclusive-OR-expression}
    1919 \rhs \nonterm{logical-AND-expression} \lstinline@&&@ \nonterm{inclusive-OR-expression}
     1898\rhs \nonterm{logical-AND-expression} ©&&© \nonterm{inclusive-OR-expression}
    19201899\end{syntax}
    19211900
    1922 \semantics The operands of the expression ``\lstinline@a && b@'' are treated as
    1923 ``\lstinline@(int)((a)!=0)@'' and ``\lstinline@(int)((b)!=0)@'', which shall both be unambiguous.
    1924 The expression has only one interpretation, which is of type \lstinline@int@.
    1925 \begin{rationale}
    1926 When the operands of a logical expression are values of built-in types, and ``\lstinline@!=@'' has not been redefined for those types, the compiler can optimize away the function calls.
    1927 
    1928 A common C idiom omits comparisons to \lstinline@0@ in the controlling expressions of loops and
    1929 \lstinline@if@ statements.
    1930 For instance, the loop below iterates as long as \lstinline@rp@ points at a \lstinline@Rational@ value that is non-zero.
     1901\semantics The operands of the expression ``©a && b©'' are treated as ``©(int)((a)!=0)©'' and ``©(int)((b)!=0)©'', which shall both be unambiguous.
     1902The expression has only one interpretation, which is of type ©int©.
     1903\begin{rationale}
     1904When the operands of a logical expression are values of built-in types, and ``©!=©'' has not been redefined for those types, the compiler can optimize away the function calls.
     1905
     1906A common C idiom omits comparisons to ©0© in the controlling expressions of loops and ©if© statements.
     1907For instance, the loop below iterates as long as ©rp© points at a ©Rational© value that is non-zero.
    19311908
    19321909\begin{lstlisting}
     
    19371914while ( rp && *rp ) { ... }
    19381915\end{lstlisting}
    1939 The logical expression calls the \lstinline@Rational@ inequality operator, passing it \lstinline@*rp@ and the \lstinline@Rational 0@, and getting a 1 or 0 as a result.
    1940 In contrast, {\CC} would apply a programmer-defined \lstinline@Rational@-to-\lstinline@int@ conversion to \lstinline@*rp@ in the equivalent situation.
    1941 The conversion to \lstinline@int@ would produce a general integer value, which is unfortunate, and possibly dangerous if the conversion was not written with this situation in mind.
     1916The logical expression calls the ©Rational© inequality operator, passing it ©*rp© and the ©Rational 0©, and getting a 1 or 0 as a result.
     1917In contrast, {\CC} would apply a programmer-defined ©Rational©-to-©int© conversion to ©*rp© in the equivalent situation.
     1918The conversion to ©int© would produce a general integer value, which is unfortunate, and possibly dangerous if the conversion was not written with this situation in mind.
    19421919\end{rationale}
    19431920
     
    19481925\lhs{logical-OR-expression}
    19491926\rhs \nonterm{logical-AND-expression}
    1950 \rhs \nonterm{logical-OR-expression} \lstinline@||@ \nonterm{logical-AND-expression}
     1927\rhs \nonterm{logical-OR-expression} ©||© \nonterm{logical-AND-expression}
    19511928\end{syntax}
    19521929
    19531930\semantics
    19541931
    1955 The operands of the expression ``\lstinline@a || b@'' are treated as ``\lstinline@(int)((a)!=0)@'' and ``\lstinline@(int)((b))!=0)@'', which shall both be unambiguous.
    1956 The expression has only one interpretation, which is of type \lstinline@int@.
     1932The operands of the expression ``©a || b©'' are treated as ``©(int)((a)!=0)©'' and ``©(int)((b))!=0)©'', which shall both be unambiguous.
     1933The expression has only one interpretation, which is of type ©int©.
    19571934
    19581935
     
    19621939\lhs{conditional-expression}
    19631940\rhs \nonterm{logical-OR-expression}
    1964 \rhs \nonterm{logical-OR-expression} \lstinline@?@ \nonterm{expression}
    1965          \lstinline@:@ \nonterm{conditional-expression}
     1941\rhs \nonterm{logical-OR-expression} ©?© \nonterm{expression}
     1942         ©:© \nonterm{conditional-expression}
    19661943\end{syntax}
    19671944
    19681945\semantics
    1969 In the conditional expression\use{?:} ``\lstinline@a?b:c@'', if the second and third operands both have an interpretation with \lstinline@void@ type, then the expression has an interpretation with type \lstinline@void@, equivalent to
     1946In the conditional expression\use{?:} ``©a?b:c©'', if the second and third operands both have an interpretation with ©void© type, then the expression has an interpretation with type ©void©, equivalent to
    19701947\begin{lstlisting}
    19711948( int)(( a)!=0) ? ( void)( b) : ( void)( c)
    19721949\end{lstlisting}
    19731950
    1974 If the second and third operands both have interpretations with non-\lstinline@void@ types, the expression is treated as if it were the call ``\lstinline@cond((a)!=0, b, c)@'', with \lstinline@cond@ declared as
     1951If the second and third operands both have interpretations with non-©void© types, the expression is treated as if it were the call ``©cond((a)!=0, b, c)©'', with ©cond© declared as
    19751952\begin{lstlisting}
    19761953forall( otype T ) T cond( int, T, T );
     
    20242001rand() ? i : l;
    20252002\end{lstlisting}
    2026 The best interpretation infers the expression's type to be \lstinline@long@ and applies the safe
    2027 \lstinline@int@-to-\lstinline@long@ conversion to \lstinline@i@.
     2003The best interpretation infers the expression's type to be ©long© and applies the safe ©int©-to-©long© conversion to ©i©.
    20282004
    20292005\begin{lstlisting}
     
    20322008rand() ? cip : vip;
    20332009\end{lstlisting}
    2034 The expression has type \lstinline@const volatile int *@, with safe conversions applied to the second and third operands to add \lstinline@volatile@ and \lstinline@const@ qualifiers, respectively.
     2010The expression has type ©const volatile int *©, with safe conversions applied to the second and third operands to add ©volatile© and ©const© qualifiers, respectively.
    20352011
    20362012\begin{lstlisting}
    20372013rand() ? cip : 0;
    20382014\end{lstlisting}
    2039 The expression has type \lstinline@const int *@, with a specialization conversion applied to
    2040 \lstinline@0@.
     2015The expression has type ©const int *©, with a specialization conversion applied to ©0©.
    20412016
    20422017
     
    20492024         \nonterm{assignment-expression}
    20502025\lhs{assignment-operator} one of
    2051 \rhs \lstinline@=@\ \ \lstinline@*=@\ \ \lstinline@/=@\ \ \lstinline@%=@\ \ \lstinline@+=@\ \ \lstinline@-=@\ \ 
    2052          \lstinline@<<=@\ \ \lstinline@>>=@\ \ \lstinline@&=@\ \ \lstinline@^=@\ \ \lstinline@|=@
     2026\rhs ©=©\ \ ©*=©\ \ ©/=©\ \ ©%=©\ \ ©+=©\ \ ©-=©\ \ 
     2027         ©<<=©\ \ ©>>=©\ \ ©&=©\ \ ©^=©\ \ ©|=©
    20532028\end{syntax}
    20542029
     
    20642039\semantics
    20652040Each interpretation of the left operand of an assignment expression is considered separately.
    2066 For each interpretation that is a bit-field or is declared with the \lstinline@register@ storage class specifier, the expression has one valid interpretation, with the type of the left operand.
     2041For each interpretation that is a bit-field or is declared with the ©register© storage class specifier, the expression has one valid interpretation, with the type of the left operand.
    20672042The right operand is cast to that type, and the assignment expression is ambiguous if either operand is.
    20682043For the remaining interpretations, the expression is rewritten, and the interpretations of the assignment expression are the interpretations of the corresponding function call.
     
    22972272\end{lstlisting}
    22982273\begin{rationale}
    2299 The pattern of overloadings for simple assignment resembles that of pointer increment and decrement, except that the polymorphic pointer assignment functions declare a \lstinline@dtype@ parameter, instead of a \lstinline@type@ parameter, because the left operand may be a pointer to an incomplete type.
    2300 \end{rationale}
    2301 
    2302 For every complete structure or union type \lstinline@S@ there exist
     2274The pattern of overloadings for simple assignment resembles that of pointer increment and decrement, except that the polymorphic pointer assignment functions declare a ©dtype© parameter, instead of a ©type© parameter, because the left operand may be a pointer to an incomplete type.
     2275\end{rationale}
     2276
     2277For every complete structure or union type ©S© there exist
    23032278% Don't use predefined: keep this out of prelude.cf.
    23042279\begin{lstlisting}
     
    23062281\end{lstlisting}
    23072282
    2308 For every extended integer type \lstinline@X@ there exist
     2283For every extended integer type ©X© there exist
    23092284% Don't use predefined: keep this out of prelude.cf.
    23102285\begin{lstlisting}
     
    23122287\end{lstlisting}
    23132288
    2314 For every complete enumerated type \lstinline@E@ there exist
     2289For every complete enumerated type ©E© there exist
    23152290% Don't use predefined: keep this out of prelude.cf.
    23162291\begin{lstlisting}
     
    23182293\end{lstlisting}
    23192294\begin{rationale}
    2320 The right-hand argument is \lstinline@int@ because enumeration constants have type \lstinline@int@.
     2295The right-hand argument is ©int© because enumeration constants have type ©int©.
    23212296\end{rationale}
    23222297
     
    25792554\end{lstlisting}
    25802555
    2581 For every extended integer type \lstinline@X@ there exist
     2556For every extended integer type ©X© there exist
    25822557% Don't use predefined: keep this out of prelude.cf.
    25832558\begin{lstlisting}
     
    25942569\end{lstlisting}
    25952570
    2596 For every complete enumerated type \lstinline@E@ there exist
     2571For every complete enumerated type ©E© there exist
    25972572% Don't use predefined: keep this out of prelude.cf.
    25982573\begin{lstlisting}
     
    26152590\lhs{expression}
    26162591\rhs \nonterm{assignment-expression}
    2617 \rhs \nonterm{expression} \lstinline@,@ \nonterm{assignment-expression}
     2592\rhs \nonterm{expression} ©,© \nonterm{assignment-expression}
    26182593\end{syntax}
    26192594
    26202595\semantics
    2621 In the comma expression ``\lstinline@a, b@'', the first operand is interpreted as
    2622 ``\lstinline@( void )(a)@'', which shall be unambiguous\index{ambiguous interpretation}.
     2596In the comma expression ``©a, b©'', the first operand is interpreted as ``©( void )(a)©'', which shall be unambiguous\index{ambiguous interpretation}.
    26232597The interpretations of the expression are the interpretations of the second operand.
    26242598
     
    26552629{ ... }
    26562630\end{lstlisting}
    2657 Without the rule, \lstinline@Complex@ would be a type in the first case, and a parameter name in the second.
     2631Without the rule, ©Complex© would be a type in the first case, and a parameter name in the second.
    26582632\end{rationale}
    26592633
     
    27122686\begin{syntax}
    27132687\lhs{forall-specifier}
    2714 \rhs \lstinline@forall@ \lstinline@(@ \nonterm{type-parameter-list} \lstinline@)@
     2688\rhs ©forall© ©(© \nonterm{type-parameter-list} ©)©
    27152689\end{syntax}
    27162690
     
    27242698} mkPair( T, T ); // illegal
    27252699\end{lstlisting}
    2726 If an instance of \lstinline@struct Pair@ was declared later in the current scope, what would the members' type be?
     2700If an instance of ©struct Pair© was declared later in the current scope, what would the members' type be?
    27272701\end{rationale}
    27282702\end{comment}
     
    27312705The \nonterm{type-parameter-list}s and assertions of the \nonterm{forall-specifier}s declare type identifiers, function and object identifiers with \Index{no linkage}.
    27322706
    2733 If, in the declaration ``\lstinline@T D@'', \lstinline@T@ contains \nonterm{forall-specifier}s and
    2734 \lstinline@D@ has the form
     2707If, in the declaration ``©T D©'', ©T© contains \nonterm{forall-specifier}s and ©D© has the form
    27352708\begin{lstlisting}
    27362709D( §\normalsize\nonterm{parameter-type-list}§ )
    2737 \end{lstlisting} then a type identifier declared by one of the \nonterm{forall-specifier}s is an \define{inferred parameter} of the function declarator if and only if it is not an inferred parameter of a function declarator in \lstinline@D@, and it is used in the type of a parameter in the following
     2710\end{lstlisting} then a type identifier declared by one of the \nonterm{forall-specifier}s is an \define{inferred parameter} of the function declarator if and only if it is not an inferred parameter of a function declarator in ©D©, and it is used in the type of a parameter in the following
    27382711\nonterm{type-parameter-list} or it and an inferred parameter are used as arguments of a
    27392712\Index{specification} in one of the \nonterm{forall-specifier}s.
     
    27482721forall( otype T ) T * alloc( void );§\use{alloc}§ int *p = alloc();
    27492722\end{lstlisting}
    2750 Here \lstinline@alloc()@ would receive \lstinline@int@ as an inferred argument, and return an
    2751 \lstinline@int *@.
    2752 In general, if a call to \lstinline@alloc()@ is a subexpression of an expression involving polymorphic functions and overloaded identifiers, there could be considerable distance between the call and the subexpression that causes \lstinline@T@ to be bound.
    2753 
    2754 With the current restriction, \lstinline@alloc()@ must be given an argument that determines
    2755 \lstinline@T@:
     2723Here ©alloc()© would receive ©int© as an inferred argument, and return an ©int *©.
     2724In general, if a call to ©alloc()© is a subexpression of an expression involving polymorphic functions and overloaded identifiers, there could be considerable distance between the call and the subexpression that causes ©T© to be bound.
     2725
     2726With the current restriction, ©alloc()© must be given an argument that determines ©T©:
    27562727\begin{lstlisting}
    27572728forall( otype T ) T * alloc( T initial_value );§\use{alloc}§
     
    27802751forall( otype T ) T fT( T );
    27812752\end{lstlisting}
    2782 \lstinline@fi()@ takes an \lstinline@int@ and returns an \lstinline@int@. \lstinline@fT()@ takes a
    2783 \lstinline@T@ and returns a \lstinline@T@, for any type \lstinline@T@.
     2753©fi()© takes an ©int© and returns an ©int©. ©fT()© takes a ©T© and returns a ©T©, for any type ©T©.
    27842754\begin{lstlisting}
    27852755int (*pfi )( int ) = fi;
    27862756forall( otype T ) T (*pfT )( T ) = fT;
    27872757\end{lstlisting}
    2788 \lstinline@pfi@ and \lstinline@pfT@ are pointers to functions. \lstinline@pfT@ is not polymorphic, but the function it points at is.
     2758©pfi© and ©pfT© are pointers to functions. ©pfT© is not polymorphic, but the function it points at is.
    27892759\begin{lstlisting}
    27902760int (*fvpfi( void ))( int ) {
     
    27952765}
    27962766\end{lstlisting}
    2797 \lstinline@fvpfi()@ and \lstinline@fvpfT()@ are functions taking no arguments and returning pointers to functions. \lstinline@fvpfT()@ is monomorphic, but the function that its return value points at is polymorphic.
     2767©fvpfi()© and ©fvpfT()© are functions taking no arguments and returning pointers to functions. ©fvpfT()© is monomorphic, but the function that its return value points at is polymorphic.
    27982768\begin{lstlisting}
    27992769forall( otype T ) int ( *fTpfi( T ) )( int );
     
    28012771forall( otype T, otype U ) U ( *fTpfU( T ) )( U );
    28022772\end{lstlisting}
    2803 \lstinline@fTpfi()@ is a polymorphic function that returns a pointer to a monomorphic function taking an integer and returning an integer.
    2804 It could return \lstinline@pfi@. \lstinline@fTpfT()@ is subtle: it is a polymorphic function returning a \emph{monomorphic} function taking and returning
    2805 \lstinline@T@, where \lstinline@T@ is an inferred parameter of \lstinline@fTpfT()@.
    2806 For instance, in the expression ``\lstinline@fTpfT(17)@'', \lstinline@T@ is inferred to be \lstinline@int@, and the returned value would have type \lstinline@int ( * )( int )@. ``\lstinline@fTpfT(17)(13)@'' and
    2807 ``\lstinline@fTpfT("yes")("no")@'' are legal, but ``\lstinline@fTpfT(17)("no")@'' is illegal.
    2808 \lstinline@fTpfU()@ is polymorphic ( in type \lstinline@T@), and returns a pointer to a function that is polymorphic ( in type \lstinline@U@). ``\lstinline@f5(17)("no")@'' is a legal expression of type
    2809 \lstinline@char *@.
     2773©fTpfi()© is a polymorphic function that returns a pointer to a monomorphic function taking an integer and returning an integer.
     2774It could return ©pfi©. ©fTpfT()© is subtle: it is a polymorphic function returning a \emph{monomorphic} function taking and returning
     2775©T©, where ©T© is an inferred parameter of ©fTpfT()©.
     2776For instance, in the expression ``©fTpfT(17)©'', ©T© is inferred to be ©int©, and the returned value would have type ©int ( * )( int )©. ``©fTpfT(17)(13)©'' and ``©fTpfT("yes")("no")©'' are legal, but ``©fTpfT(17)("no")©'' is illegal.
     2777©fTpfU()© is polymorphic ( in type ©T©), and returns a pointer to a function that is polymorphic ( in type ©U©). ``©f5(17)("no")©'' is a legal expression of type ©char *©.
    28102778\begin{lstlisting}
    28112779forall( otype T, otype U, otype V ) U * f( T *, U, V * const );
    28122780forall( otype U, otype V, otype W ) U * g( V *, U, W * const );
    28132781\end{lstlisting}
    2814 The functions \lstinline@f()@ and \lstinline@g()@ have compatible types.
     2782The functions ©f()© and ©g()© have compatible types.
    28152783Let \(f\) and \(g\) be their types;
    2816 then \(f_1\) = \lstinline@T@, \(f_2\) = \lstinline@U@, \(f_3\) = \lstinline@V@, \(g_1\)
    2817 = \lstinline@V@, \(g_2\) = \lstinline@U@, and \(g_3\) = \lstinline@W@.
     2784then \(f_1\) = ©T©, \(f_2\) = ©U©, \(f_3\) = ©V©, \(g_1\)
     2785= ©V©, \(g_2\) = ©U©, and \(g_3\) = ©W©.
    28182786Replacing every \(f_i\) by \(g_i\) in \(f\) gives
    28192787\begin{lstlisting}
     
    28212789\end{lstlisting} which has a return type and parameter list that is compatible with \(g\).
    28222790\begin{rationale}
    2823 The word ``\lstinline@type@'' in a forall specifier is redundant at the moment, but I want to leave room for inferred parameters of ordinary types in case parameterized types get added one day.
     2791The word ``©type©'' in a forall specifier is redundant at the moment, but I want to leave room for inferred parameters of ordinary types in case parameterized types get added one day.
    28242792
    28252793Even without parameterized types, I might try to allow
     
    28472815\subsection{Type qualifiers}
    28482816
    2849 \CFA defines a new type qualifier \lstinline@lvalue@\impl{lvalue}\index{lvalue}.
     2817\CFA defines a new type qualifier ©lvalue©\impl{lvalue}\index{lvalue}.
    28502818\begin{syntax}
    28512819\oldlhs{type-qualifier}
    2852 \rhs \lstinline@lvalue@
     2820\rhs ©lvalue©
    28532821\end{syntax}
    28542822
     
    28582826\semantics
    28592827An object's type may be a restrict-qualified type parameter.
    2860 \lstinline@restrict@ does not establish any special semantics in that case.
     2828©restrict© does not establish any special semantics in that case.
    28612829
    28622830\begin{rationale}
     
    28642832\end{rationale}
    28652833
    2866 \lstinline@lvalue@ may be used to qualify the return type of a function type.
    2867 Let \lstinline@T@ be an unqualified version of a type;
    2868 then the result of calling a function with return type
    2869 \lstinline@lvalue T@ is a \Index{modifiable lvalue} of type \lstinline@T@.
    2870 \lstinline@const@\use{const} and \lstinline@volatile@\use{volatile} qualifiers may also be added to indicate that the function result is a constant or volatile lvalue.
    2871 \begin{rationale}
    2872 The \lstinline@const@ and \lstinline@volatile@ qualifiers can only be sensibly used to qualify the return type of a function if the \lstinline@lvalue@ qualifier is also used.
     2834©lvalue© may be used to qualify the return type of a function type.
     2835Let ©T© be an unqualified version of a type;
     2836then the result of calling a function with return type ©lvalue T© is a \Index{modifiable lvalue} of type ©T©.
     2837©const©\use{const} and ©volatile©\use{volatile} qualifiers may also be added to indicate that the function result is a constant or volatile lvalue.
     2838\begin{rationale}
     2839The ©const© and ©volatile© qualifiers can only be sensibly used to qualify the return type of a function if the ©lvalue© qualifier is also used.
    28732840\end{rationale}
    28742841
     
    28772844
    28782845\begin{rationale}
    2879 \lstinline@lvalue@ provides some of the functionality of {\CC}'s ``\lstinline@T&@'' ( reference to object of type \lstinline@T@) type.
     2846©lvalue© provides some of the functionality of {\CC}'s ``©T&©'' ( reference to object of type ©T©) type.
    28802847Reference types have four uses in {\CC}.
    28812848\begin{itemize}
     
    28842851
    28852852\item
    2886 A reference can be used to define an alias for a complicated lvalue expression, as a way of getting some of the functionality of the Pascal \lstinline@with@ statement.
     2853A reference can be used to define an alias for a complicated lvalue expression, as a way of getting some of the functionality of the Pascal ©with© statement.
    28872854The following {\CC} code gives an example.
    28882855\begin{lstlisting}
     
    28972864A reference parameter can be used to allow a function to modify an argument without forcing the caller to pass the address of the argument.
    28982865This is most useful for user-defined assignment operators.
    2899 In {\CC}, plain assignment is done by a function called ``\lstinline@operator=@'', and the two expressions
     2866In {\CC}, plain assignment is done by a function called ``©operator=©'', and the two expressions
    29002867\begin{lstlisting}
    29012868a = b;
    29022869operator=( a, b );
    29032870\end{lstlisting} are equivalent.
    2904 If \lstinline@a@ and \lstinline@b@ are of type \lstinline@T@, then the first parameter of \lstinline@operator=@ must have type ``\lstinline@T&@''.
    2905 It cannot have type
    2906 \lstinline@T@, because then assignment couldn't alter the variable, and it can't have type
    2907 ``\lstinline@T *@'', because the assignment would have to be written ``\lstinline@&a = b;@''.
    2908 
    2909 In the case of user-defined operators, this could just as well be handled by using pointer types and by changing the rewrite rules so that ``\lstinline@a = b;@'' is equivalent to
    2910 ``\lstinline@operator=(&( a), b )@''.
    2911 Reference parameters of ``normal'' functions are Bad Things, because they remove a useful property of C function calls: an argument can only be modified by a function if it is preceded by ``\lstinline@&@''.
     2871If ©a© and ©b© are of type ©T©, then the first parameter of ©operator=© must have type ``©T&©''.
     2872It cannot have type ©T©, because then assignment couldn't alter the variable, and it can't have type ``©T *©'', because the assignment would have to be written ``©&a = b;©''.
     2873
     2874In the case of user-defined operators, this could just as well be handled by using pointer types and by changing the rewrite rules so that ``©a = b;©'' is equivalent to ``©operator=(&( a), b )©''.
     2875Reference parameters of ``normal'' functions are Bad Things, because they remove a useful property of C function calls: an argument can only be modified by a function if it is preceded by ``©&©''.
    29122876
    29132877\item
    29142878References to \Index{const-qualified} types can be used instead of value parameters.  Given the
    2915 {\CC} function call ``\lstinline@fiddle( a_thing )@'', where the type of \lstinline@a_thing@ is
    2916 \lstinline@Thing@, the type of \lstinline@fiddle@ could be either of
     2879{\CC} function call ``©fiddle( a_thing )©'', where the type of ©a_thing© is
     2880©Thing©, the type of ©fiddle© could be either of
    29172881\begin{lstlisting}
    29182882void fiddle( Thing );
    29192883void fiddle( const Thing & );
    29202884\end{lstlisting}
    2921 If the second form is used, then constructors and destructors are not invoked to create a temporary variable at the call site ( and it is bad style for the caller to make any assumptions about such things), and within \lstinline@fiddle@ the parameter is subject to the usual problems caused by aliases.
    2922 The reference form might be chosen for efficiency's sake if \lstinline@Thing@s are too large or their constructors or destructors are too expensive.
     2885If the second form is used, then constructors and destructors are not invoked to create a temporary variable at the call site ( and it is bad style for the caller to make any assumptions about such things), and within ©fiddle© the parameter is subject to the usual problems caused by aliases.
     2886The reference form might be chosen for efficiency's sake if ©Thing©s are too large or their constructors or destructors are too expensive.
    29232887An implementation may switch between them without causing trouble for well-behaved clients.
    29242888This leaves the implementor to define ``too large'' and ``too expensive''.
     
    29282892void fiddle( const volatile Thing );
    29292893\end{lstlisting} with call-by-reference.
    2930 Since it knows all about the size of \lstinline@Thing@s and the parameter passing mechanism, it should be able to come up with a better definition of ``too large'', and may be able to make a good guess at ``too expensive''.
     2894Since it knows all about the size of ©Thing©s and the parameter passing mechanism, it should be able to come up with a better definition of ``too large'', and may be able to make a good guess at ``too expensive''.
    29312895\end{itemize}
    29322896
     
    29482912\begin{syntax}
    29492913\lhs{spec-definition}
    2950 \rhs \lstinline@spec@ \nonterm{identifier}
    2951         \lstinline@(@ \nonterm{type-parameter-list} \lstinline@)@
    2952         \lstinline@{@ \nonterm{spec-declaration-list}\opt \lstinline@}@
     2914\rhs ©spec© \nonterm{identifier}
     2915        ©(© \nonterm{type-parameter-list} ©)©
     2916        ©{© \nonterm{spec-declaration-list}\opt ©}©
    29532917\lhs{spec-declaration-list}
    2954 \rhs \nonterm{spec-declaration} \lstinline@;@
    2955 \rhs \nonterm{spec-declaration-list} \nonterm{spec-declaration} \lstinline@;@
     2918\rhs \nonterm{spec-declaration} ©;©
     2919\rhs \nonterm{spec-declaration-list} \nonterm{spec-declaration} ©;©
    29562920\lhs{spec-declaration}
    29572921\rhs \nonterm{specifier-qualifier-list} \nonterm{declarator-list}
    29582922\lhs{declarator-list}
    29592923\rhs \nonterm{declarator}
    2960 \rhs \nonterm{declarator-list} \lstinline@,@ \nonterm{declarator}
     2924\rhs \nonterm{declarator-list} ©,© \nonterm{declarator}
    29612925\end{syntax}
    29622926\begin{rationale}
     
    29802944\rhs \nonterm{assertion-list} \nonterm{assertion}
    29812945\lhs{assertion}
    2982 \rhs \lstinline@|@ \nonterm{identifier} \lstinline@(@ \nonterm{type-name-list} \lstinline@)@
    2983 \rhs \lstinline@|@ \nonterm{spec-declaration}
     2946\rhs ©|© \nonterm{identifier} ©(© \nonterm{type-name-list} ©)©
     2947\rhs ©|© \nonterm{spec-declaration}
    29842948\lhs{type-name-list}
    29852949\rhs \nonterm{type-name}
    2986 \rhs \nonterm{type-name-list} \lstinline@,@ \nonterm{type-name}
     2950\rhs \nonterm{type-name-list} ©,© \nonterm{type-name}
    29872951\end{syntax}
    29882952
     
    29912955The \nonterm{type-name-list} shall contain one \nonterm{type-name} argument for each \nonterm{type-parameter} in that specification's \nonterm{spec-parameter-list}.
    29922956If the
    2993 \nonterm{type-parameter} uses type-class \lstinline@type@\use{type}, the argument shall be the type name of an \Index{object type};
    2994 if it uses \lstinline@dtype@, the argument shall be the type name of an object type or an \Index{incomplete type};
    2995 and if it uses \lstinline@ftype@, the argument shall be the type name of a \Index{function type}.
     2957\nonterm{type-parameter} uses type-class ©type©\use{type}, the argument shall be the type name of an \Index{object type};
     2958if it uses ©dtype©, the argument shall be the type name of an object type or an \Index{incomplete type};
     2959and if it uses ©ftype©, the argument shall be the type name of a \Index{function type}.
    29962960
    29972961\semantics
     
    30232987trait sum_list( otype List, otype Element | summable( Element ) | list_of( List, Element ) ) {};
    30242988\end{lstlisting}
    3025 \lstinline@sum_list@ contains seven declarations, which describe a list whose elements can be added up.
    3026 The assertion ``\lstinline@|sum_list( i_list, int )@''\use{sum_list} produces the assertion parameters
     2989©sum_list© contains seven declarations, which describe a list whose elements can be added up.
     2990The assertion ``©|sum_list( i_list, int )©''\use{sum_list} produces the assertion parameters
    30272991\begin{lstlisting}
    30282992int ?+=?( int *, int );
     
    30413005\lhs{type-parameter-list}
    30423006\rhs \nonterm{type-parameter}
    3043 \rhs \nonterm{type-parameter-list} \lstinline@,@ \nonterm{type-parameter}
     3007\rhs \nonterm{type-parameter-list} ©,© \nonterm{type-parameter}
    30443008\lhs{type-parameter}
    30453009\rhs \nonterm{type-class} \nonterm{identifier} \nonterm{assertion-list}\opt
    30463010\lhs{type-class}
    3047 \rhs \lstinline@type@
    3048 \rhs \lstinline@dtype@
    3049 \rhs \lstinline@ftype@
     3011\rhs ©type©
     3012\rhs ©dtype©
     3013\rhs ©ftype©
    30503014\lhs{type-declaration}
    3051 \rhs \nonterm{storage-class-specifier}\opt \lstinline@type@ \nonterm{type-declarator-list} \verb|;|
     3015\rhs \nonterm{storage-class-specifier}\opt ©type© \nonterm{type-declarator-list} \verb|;|
    30523016\lhs{type-declarator-list}
    30533017\rhs \nonterm{type-declarator}
    3054 \rhs \nonterm{type-declarator-list} \lstinline@,@ \nonterm{type-declarator}
     3018\rhs \nonterm{type-declarator-list} ©,© \nonterm{type-declarator}
    30553019\lhs{type-declarator}
    3056 \rhs \nonterm{identifier} \nonterm{assertion-list}\opt \lstinline@=@ \nonterm{type-name}
     3020\rhs \nonterm{identifier} \nonterm{assertion-list}\opt ©=© \nonterm{type-name}
    30573021\rhs \nonterm{identifier} \nonterm{assertion-list}\opt
    30583022\end{syntax}
     
    30653029
    30663030An identifier declared by a \nonterm{type-parameter} has \Index{no linkage}.
    3067 Identifiers declared with type-class \lstinline@type@\use{type} are \Index{object type}s;
    3068 those declared with type-class
    3069 \lstinline@dtype@\use{dtype} are \Index{incomplete type}s;
    3070 and those declared with type-class
    3071 \lstinline@ftype@\use{ftype} are \Index{function type}s.
     3031Identifiers declared with type-class ©type©\use{type} are \Index{object type}s;
     3032those declared with type-class ©dtype©\use{dtype} are \Index{incomplete type}s;
     3033and those declared with type-class ©ftype©\use{ftype} are \Index{function type}s.
    30723034The identifier has \Index{block scope} that terminates at the end of the \nonterm{spec-declaration-list} or polymorphic function that contains the \nonterm{type-parameter}.
    30733035
     
    30773039Within the scope of the declaration, \Index{implicit conversion}s can be performed between the defined type and the implementation type, and between pointers to the defined type and pointers to the implementation type.
    30783040
    3079 A type declaration without an \Index{initializer} and without a \Index{storage-class specifier} or with storage-class specifier \lstinline@static@\use{static} defines an \Index{incomplete type}.
     3041A type declaration without an \Index{initializer} and without a \Index{storage-class specifier} or with storage-class specifier ©static©\use{static} defines an \Index{incomplete type}.
    30803042If a
    30813043\Index{translation unit} or \Index{block} contains one or more such declarations for an identifier, it must contain exactly one definition of the identifier ( but not in an enclosed block, which would define a new type known only within that block).
     
    30963058\end{rationale}
    30973059
    3098 A type declaration without an initializer and with \Index{storage-class specifier}
    3099 \lstinline@extern@\use{extern} is an \define{opaque type declaration}.
     3060A type declaration without an initializer and with \Index{storage-class specifier} ©extern©\use{extern} is an \define{opaque type declaration}.
    31003061Opaque types are
    31013062\Index{object type}s.
     
    31123073\end{rationale}
    31133074
    3114 An \Index{incomplete type} which is not a qualified version\index{qualified type} of a type is a value of \Index{type-class} \lstinline@dtype@.
    3115 An object type\index{object types} which is not a qualified version of a type is a value of type-classes \lstinline@type@ and \lstinline@dtype@.
     3075An \Index{incomplete type} which is not a qualified version\index{qualified type} of a type is a value of \Index{type-class} ©dtype©.
     3076An object type\index{object types} which is not a qualified version of a type is a value of type-classes ©type© and ©dtype©.
    31163077A
    3117 \Index{function type} is a value of type-class \lstinline@ftype@.
     3078\Index{function type} is a value of type-class ©ftype©.
    31183079\begin{rationale}
    31193080Syntactically, a type value is a \nonterm{type-name}, which is a declaration for an object which omits the identifier being declared.
     
    31243085
    31253086Type qualifiers are a weak point of C's type system.
    3126 Consider the standard library function
    3127 \lstinline@strchr()@ which, given a string and a character, returns a pointer to the first occurrence of the character in the string.
     3087Consider the standard library function ©strchr()© which, given a string and a character, returns a pointer to the first occurrence of the character in the string.
    31283088\begin{lstlisting}
    31293089char *strchr( const char *s, int c ) {§\impl{strchr}§
     
    31343094}
    31353095\end{lstlisting}
    3136 The parameter \lstinline@s@ must be \lstinline@const char *@, because \lstinline@strchr()@ might be used to search a constant string, but the return type must be \lstinline@char *@, because the result might be used to modify a non-constant string.
    3137 Hence the body must perform a cast, and ( even worse)
    3138 \lstinline@strchr()@ provides a type-safe way to attempt to modify constant strings.
    3139 What is needed is some way to say that \lstinline@s@'s type might contain qualifiers, and the result type has exactly the same qualifiers.
     3096The parameter ©s© must be ©const char *©, because ©strchr()© might be used to search a constant string, but the return type must be ©char *©, because the result might be used to modify a non-constant string.
     3097Hence the body must perform a cast, and ( even worse) ©strchr()© provides a type-safe way to attempt to modify constant strings.
     3098What is needed is some way to say that ©s©'s type might contain qualifiers, and the result type has exactly the same qualifiers.
    31403099Polymorphic functions do not provide a fix for this deficiency\index{deficiencies!pointers to qualified types}, because type qualifiers are not part of type values.
    3141 Instead, overloading can be used to define \lstinline@strchr()@ for each combination of qualifiers.
     3100Instead, overloading can be used to define ©strchr()© for each combination of qualifiers.
    31423101\end{rationale}
    31433102
     
    31633122};
    31643123\end{lstlisting}
    3165 Without this restriction, \CFA might require ``module initialization'' code ( since
    3166 \lstinline@Rational@ has external linkage, it must be created before any other translation unit instantiates it), and would force an ordering on the initialization of the translation unit that defines \lstinline@Huge@ and the translation that declares \lstinline@Rational@.
     3124Without this restriction, \CFA might require ``module initialization'' code ( since ©Rational© has external linkage, it must be created before any other translation unit instantiates it), and would force an ordering on the initialization of the translation unit that defines ©Huge© and the translation that declares ©Rational©.
    31673125
    31683126A benefit of the restriction is that it prevents the declaration in separate translation units of types that contain each other, which would be hard to prevent otherwise.
     
    31813139\nonterm{struct-declaration}, type declarations can not be structure members.
    31823140The form of
    3183 \nonterm{type-declaration} forbids arrays of, pointers to, and functions returning \lstinline@type@.
     3141\nonterm{type-declaration} forbids arrays of, pointers to, and functions returning ©type©.
    31843142Hence the syntax of \nonterm{type-specifier} does not have to be extended to allow type-valued expressions.
    31853143It also side-steps the problem of type-valued expressions producing different values in different declarations.
     
    31983156§\ldots§ int * ip = new( int );
    31993157\end{lstlisting}
    3200 This looks sensible, but \CFA's declaration-before-use rules mean that ``\lstinline@T@'' in the function body refers to the parameter, but the ``\lstinline@T@'' in the return type refers to the meaning of \lstinline@T@ in the scope that contains \lstinline@new@;
     3158This looks sensible, but \CFA's declaration-before-use rules mean that ``©T©'' in the function body refers to the parameter, but the ``©T©'' in the return type refers to the meaning of ©T© in the scope that contains ©new©;
    32013159it could be undefined, or a type name, or a function or variable name.
    32023160Nothing good can result from such a situation.
     
    32153173f2( v2 );
    32163174\end{lstlisting}
    3217 \lstinline@V1@ is passed by value, so \lstinline@f1()@'s assignment to \lstinline@a[0]@ does not modify v1.  \lstinline@V2@ is converted to a pointer, so \lstinline@f2()@ modifies \lstinline@v2[0]@.
     3175©V1© is passed by value, so ©f1()©'s assignment to ©a[0]© does not modify v1.  ©V2© is converted to a pointer, so ©f2()© modifies ©v2[0]©.
    32183176
    32193177A translation unit containing the declarations
     
    32213179extern type Complex;§\use{Complex}§ // opaque type declaration
    32223180extern float abs( Complex );§\use{abs}§
    3223 \end{lstlisting} can contain declarations of complex numbers, which can be passed to \lstinline@abs@.
    3224 Some other translation unit must implement \lstinline@Complex@ and \lstinline@abs@.
     3181\end{lstlisting} can contain declarations of complex numbers, which can be passed to ©abs©.
     3182Some other translation unit must implement ©Complex© and ©abs©.
    32253183That unit might contain the declarations
    32263184\begin{lstlisting}
     
    32313189}
    32323190\end{lstlisting}
    3233 Note that \lstinline@c@ is implicitly converted to a \lstinline@struct@ so that its components can be retrieved.
     3191Note that ©c© is implicitly converted to a ©struct© so that its components can be retrieved.
    32343192
    32353193\begin{lstlisting}
     
    32393197}
    32403198\end{lstlisting}
    3241 \lstinline@t1@ must be cast to its implementation type to prevent infinite recursion.
     3199©t1© must be cast to its implementation type to prevent infinite recursion.
    32423200
    32433201\begin{rationale}
    32443202Within the scope of a type definition, an instance of the type can be viewed as having that type or as having the implementation type.
    3245 In the \lstinline@Time_of_day@ example, the difference is important.
     3203In the ©Time_of_day© example, the difference is important.
    32463204Different languages have treated the distinction between the abstraction and the implementation in different ways.
    32473205\begin{itemize}
    32483206\item
    32493207Inside a Clu cluster \cite{CLU}, the declaration of an instance states which view applies.
    3250 Two primitives called \lstinline@up@ and \lstinline@down@ can be used to convert between the views.
     3208Two primitives called ©up© and ©down© can be used to convert between the views.
    32513209\item
    32523210The Simula class \cite{SIMULA87} is essentially a record type.
    32533211Since the only operations on a record are member selection and assignment, which can not be overloaded, there is never any ambiguity as to whether the abstraction or the implementation view is being used.
    32543212In {\CC}
    3255 \cite{C++}, operations on class instances include assignment and ``\lstinline@&@'', which can be overloaded.
     3213\cite{C++}, operations on class instances include assignment and ``©&©'', which can be overloaded.
    32563214A ``scope resolution'' operator can be used inside the class to specify whether the abstract or implementation version of the operation should be used.
    32573215\item
     
    32663224In this case, explicit conversions between the derived type and the old type can be used.
    32673225\end{itemize}
    3268 \CFA's rules are like Clu's, except that implicit conversions and conversion costs allow it to do away with most uses of \lstinline@up@ and \lstinline@down@.
     3226\CFA's rules are like Clu's, except that implicit conversions and conversion costs allow it to do away with most uses of ©up© and ©down©.
    32693227\end{rationale}
    32703228
     
    32723230\subsubsection{Default functions and objects}
    32733231
    3274 A declaration\index{type declaration} of a type identifier \lstinline@T@ with type-class
    3275 \lstinline@type@ implicitly declares a \define{default assignment} function
    3276 \lstinline@T ?=?( T *, T )@\use{?=?}, with the same \Index{scope} and \Index{linkage} as the identifier \lstinline@T@.
     3232A declaration\index{type declaration} of a type identifier ©T© with type-class ©type© implicitly declares a \define{default assignment} function ©T ?=?( T *, T )©\use{?=?}, with the same \Index{scope} and \Index{linkage} as the identifier ©T©.
    32773233\begin{rationale}
    32783234Assignment is central to C's imperative programming style, and every existing C object type has assignment defined for it ( except for array types, which are treated as pointer types for purposes of assignment).
    32793235Without this rule, nearly every inferred type parameter would need an accompanying assignment assertion parameter.
    3280 If a type parameter should not have an assignment operation,
    3281 \lstinline@dtype@ should be used.
     3236If a type parameter should not have an assignment operation, ©dtype© should be used.
    32823237If a type should not have assignment defined, the user can define an assignment function that causes a run-time error, or provide an external declaration but no definition and thus cause a link-time error.
    32833238\end{rationale}
    32843239
    3285 A definition\index{type definition} of a type identifier \lstinline@T@ with \Index{implementation type} \lstinline@I@ and type-class \lstinline@type@ implicitly defines a default assignment function.
    3286 A definition\index{type definition} of a type identifier \lstinline@T@ with implementation type \lstinline@I@ and an assertion list implicitly defines \define{default function}s and
     3240A definition\index{type definition} of a type identifier ©T© with \Index{implementation type} ©I© and type-class ©type© implicitly defines a default assignment function.
     3241A definition\index{type definition} of a type identifier ©T© with implementation type ©I© and an assertion list implicitly defines \define{default function}s and
    32873242\define{default object}s as declared by the assertion declarations.
    3288 The default objects and functions have the same \Index{scope} and \Index{linkage} as the identifier \lstinline@T@.
     3243The default objects and functions have the same \Index{scope} and \Index{linkage} as the identifier ©T©.
    32893244Their values are determined as follows:
    32903245\begin{itemize}
    32913246\item
    3292 If at the definition of \lstinline@T@ there is visible a declaration of an object with the same name as the default object, and if the type of that object with all occurrence of \lstinline@I@ replaced by \lstinline@T@ is compatible with the type of the default object, then the default object is initialized with that object.
    3293 Otherwise the scope of the declaration of \lstinline@T@ must contain a definition of the default object.
     3247If at the definition of ©T© there is visible a declaration of an object with the same name as the default object, and if the type of that object with all occurrence of ©I© replaced by ©T© is compatible with the type of the default object, then the default object is initialized with that object.
     3248Otherwise the scope of the declaration of ©T© must contain a definition of the default object.
    32943249
    32953250\item
    3296 If at the definition of \lstinline@T@ there is visible a declaration of a function with the same name as the default function, and if the type of that function with all occurrence of \lstinline@I@ replaced by \lstinline@T@ is compatible with the type of the default function, then the default function calls that function after converting its arguments and returns the converted result.
    3297 
    3298 Otherwise, if \lstinline@I@ contains exactly one anonymous member\index{anonymous member} such that at the definition of \lstinline@T@ there is visible a declaration of a function with the same name as the default function, and the type of that function with all occurrences of the anonymous member's type in its parameter list replaced by \lstinline@T@ is compatible with the type of the default function, then the default function calls that function after converting its arguments and returns the result.
    3299 
    3300 Otherwise the scope of the declaration of \lstinline@T@ must contain a definition of the default function.
     3251If at the definition of ©T© there is visible a declaration of a function with the same name as the default function, and if the type of that function with all occurrence of ©I© replaced by ©T© is compatible with the type of the default function, then the default function calls that function after converting its arguments and returns the converted result.
     3252
     3253Otherwise, if ©I© contains exactly one anonymous member\index{anonymous member} such that at the definition of ©T© there is visible a declaration of a function with the same name as the default function, and the type of that function with all occurrences of the anonymous member's type in its parameter list replaced by ©T© is compatible with the type of the default function, then the default function calls that function after converting its arguments and returns the result.
     3254
     3255Otherwise the scope of the declaration of ©T© must contain a definition of the default function.
    33013256\end{itemize}
    33023257\begin{rationale}
     
    33043259\end{rationale}
    33053260
    3306 A function or object with the same type and name as a default function or object that is declared within the scope of the definition of \lstinline@T@ replaces the default function or object.
     3261A function or object with the same type and name as a default function or object that is declared within the scope of the definition of ©T© replaces the default function or object.
    33073262
    33083263\examples
     
    33143269Pair b = { 1, 1 };
    33153270\end{lstlisting}
    3316 The definition of \lstinline@Pair@ implicitly defines two objects \lstinline@a@ and \lstinline@b@.
    3317 \lstinline@Pair a@ inherits its value from the \lstinline@struct impl a@.
    3318 The definition of
    3319 \lstinline@Pair b@ is compulsory because there is no \lstinline@struct impl b@ to construct a value from.
     3271The definition of ©Pair© implicitly defines two objects ©a© and ©b©.
     3272©Pair a© inherits its value from the ©struct impl a©.
     3273The definition of ©Pair b© is compulsory because there is no ©struct impl b© to construct a value from.
    33203274\begin{lstlisting}
    33213275trait ss( otype T ) {
     
    33303284Doodad clone( Doodad ) { ... }
    33313285\end{lstlisting}
    3332 The definition of \lstinline@Doodad@ implicitly defines three functions:
     3286The definition of ©Doodad© implicitly defines three functions:
    33333287\begin{lstlisting}
    33343288Doodad ?=?( Doodad *, Doodad );
     
    33363290void munge( Doodad * );
    33373291\end{lstlisting}
    3338 The assignment function inherits \lstinline@struct doodad@'s assignment function because the types match when \lstinline@struct doodad@ is replaced by \lstinline@Doodad@ throughout.
    3339 \lstinline@munge()@ inherits \lstinline@Whatsit@'s \lstinline@munge()@ because the types match when
    3340 \lstinline@Whatsit@ is replaced by \lstinline@Doodad@ in the parameter list. \lstinline@clone()@ does \emph{not} inherit \lstinline@Whatsit@'s \lstinline@clone()@: replacement in the parameter list yields ``\lstinline@Whatsit clone( Doodad )@'', which is not compatible with
    3341 \lstinline@Doodad@'s \lstinline@clone()@'s type.
    3342 Hence the definition of
    3343 ``\lstinline@Doodad clone( Doodad )@'' is necessary.
     3292The assignment function inherits ©struct doodad©'s assignment function because the types match when ©struct doodad©  is replaced by ©Doodad© throughout.
     3293©munge()© inherits ©Whatsit©'s ©munge()© because the types match when ©Whatsit© is replaced by ©Doodad© in the parameter list. ©clone()© does \emph{not} inherit ©Whatsit©'s ©clone()©: replacement in the parameter list yields ``©Whatsit clone( Doodad )©'', which is not compatible with ©Doodad©'s ©clone()©'s type.
     3294Hence the definition of ``©Doodad clone( Doodad )©'' is necessary.
    33443295
    33453296Default functions and objects are subject to the normal scope rules.
     
    33813332\begin{syntax}
    33823333\oldlhs{labeled-statement}
    3383 \rhs \lstinline@case@ \nonterm{case-value-list} : \nonterm{statement}
     3334\rhs ©case© \nonterm{case-value-list} : \nonterm{statement}
    33843335\lhs{case-value-list}
    33853336\rhs \nonterm{case-value}
    3386 \rhs \nonterm{case-value-list} \lstinline@,@ \nonterm{case-value}
     3337\rhs \nonterm{case-value-list} ©,© \nonterm{case-value}
    33873338\lhs{case-value}
    33883339\rhs \nonterm{constant-expression}
    33893340\rhs \nonterm{subrange}
    33903341\lhs{subrange}
    3391 \rhs \nonterm{constant-expression} \lstinline@~@ \nonterm{constant-expression}
     3342\rhs \nonterm{constant-expression} ©~© \nonterm{constant-expression}
    33923343\end{syntax}
    33933344
     
    34023353case 1~4, 9~14, 27~32:
    34033354\end{lstlisting}
    3404 The \lstinline@case@ and \lstinline@default@ clauses are restricted within the \lstinline@switch@ and \lstinline@choose@ statements, precluding Duff's device.
     3355The ©case© and ©default© clauses are restricted within the ©switch© and ©choose© statements, precluding Duff's device.
    34053356
    34063357
    34073358\subsection{Expression and null statements}
    34083359
    3409 The expression in an expression statement is treated as being cast to \lstinline@void@.
     3360The expression in an expression statement is treated as being cast to ©void©.
    34103361
    34113362
     
    34143365\begin{syntax}
    34153366\oldlhs{selection-statement}
    3416 \rhs \lstinline@choose@ \lstinline@(@ \nonterm{expression} \lstinline@)@ \nonterm{statement}
     3367\rhs ©choose© ©(© \nonterm{expression} ©)© \nonterm{statement}
    34173368\end{syntax}
    34183369
    3419 The controlling expression \lstinline@E@ in the \lstinline@switch@ and \lstinline@choose@ statement:
     3370The controlling expression ©E© in the ©switch© and ©choose© statement:
    34203371\begin{lstlisting}
    34213372switch ( E ) ...
     
    34233374\end{lstlisting} may have more than one interpretation, but it shall have only one interpretation with an integral type.
    34243375An \Index{integer promotion} is performed on the expression if necessary.
    3425 The constant expressions in \lstinline@case@ statements with the switch are converted to the promoted type.
     3376The constant expressions in ©case© statements with the switch are converted to the promoted type.
    34263377
    34273378
     
    34293380\subsubsection[The choose statement]{The \lstinline@choose@ statement}
    34303381
    3431 The \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.
    3432 The \lstinline@fallthru@ statement is used to fall through to the next \lstinline@case@ or \lstinline@default@ labeled statement.
     3382The ©choose© statement is the same as the ©switch© statement except control transfers to the end of the ©choose© statement at a ©case© or ©default© labeled statement.
     3383The ©fallthru© statement is used to fall through to the next ©case© or ©default© labeled statement.
    34333384The following have identical meaning:
    34343385\begin{flushleft}
     
    34553406\end{tabular}
    34563407\end{flushleft}
    3457 The \lstinline@choose@ statement addresses the problem of accidental fall-through associated with the \lstinline@switch@ statement.
     3408The ©choose© statement addresses the problem of accidental fall-through associated with the ©switch© statement.
    34583409
    34593410
    34603411\subsection{Iteration statements}
    34613412
    3462 The controlling expression \lstinline@E@ in the loops
     3413The controlling expression ©E© in the loops
    34633414\begin{lstlisting}
    34643415if ( E ) ...
    34653416while ( E ) ...
    34663417do ... while ( E );
    3467 \end{lstlisting} is treated as ``\lstinline@( int )((E)!=0)@''.
     3418\end{lstlisting}
     3419is treated as ``©( int )((E)!=0)©''.
    34683420
    34693421The statement
     
    34803432\begin{syntax}
    34813433\oldlhs{jump-statement}
    3482 \rhs \lstinline@continue@ \nonterm{identifier}\opt
    3483 \rhs \lstinline@break@ \nonterm{identifier}\opt
     3434\rhs ©continue© \nonterm{identifier}\opt
     3435\rhs ©break© \nonterm{identifier}\opt
    34843436\rhs \ldots
    3485 \rhs \lstinline@throw@ \nonterm{assignment-expression}\opt
    3486 \rhs \lstinline@throwResume@ \nonterm{assignment-expression}\opt \nonterm{at-expression}\opt
    3487 \lhs{at-expression} \lstinline@_At@ \nonterm{assignment-expression}
     3437\rhs ©throw© \nonterm{assignment-expression}\opt
     3438\rhs ©throwResume© \nonterm{assignment-expression}\opt \nonterm{at-expression}\opt
     3439\lhs{at-expression} ©_At© \nonterm{assignment-expression}
    34883440\end{syntax}
    34893441
    3490 Labeled \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.
     3442Labeled ©continue© and ©break© allow useful but restricted control-flow that reduces the need for the ©goto© statement for exiting multiple nested control-structures.
    34913443\begin{lstlisting}
    34923444L1: {                                                   // compound
     
    35173469\subsubsection[The continue statement]{The \lstinline@continue@ statement}
    35183470
    3519 The identifier in a \lstinline@continue@ statement shall name a label located on an enclosing iteration statement.
     3471The identifier in a ©continue© statement shall name a label located on an enclosing iteration statement.
    35203472
    35213473
    35223474\subsubsection[The break statement]{The \lstinline@break@ statement}
    35233475
    3524 The identifier in a \lstinline@break@ statement shall name a label located on an enclosing compound, selection or iteration statement.
     3476The identifier in a ©break© statement shall name a label located on an enclosing compound, selection or iteration statement.
    35253477
    35263478
    35273479\subsubsection[The return statement]{The \lstinline@return@ statement}
    35283480
    3529 An expression in a \lstinline@return@ statement is treated as being cast to the result type of the function.
     3481An expression in a ©return© statement is treated as being cast to the result type of the function.
    35303482
    35313483
     
    35423494\begin{syntax}
    35433495\lhs{exception-statement}
    3544 \rhs \lstinline@try@ \nonterm{compound-statement} \nonterm{handler-list}
    3545 \rhs \lstinline@try@ \nonterm{compound-statement} \nonterm{finally-clause}
    3546 \rhs \lstinline@try@ \nonterm{compound-statement} \nonterm{handler-list} \nonterm{finally-clause}
     3496\rhs ©try© \nonterm{compound-statement} \nonterm{handler-list}
     3497\rhs ©try© \nonterm{compound-statement} \nonterm{finally-clause}
     3498\rhs ©try© \nonterm{compound-statement} \nonterm{handler-list} \nonterm{finally-clause}
    35473499\lhs{handler-list}
    35483500\rhs \nonterm{handler-clause}
    3549 \rhs \lstinline@catch@ \lstinline@(@ \ldots \lstinline@)@ \nonterm{compound-statement}
    3550 \rhs \nonterm{handler-clause} \lstinline@catch@ \lstinline@(@ \ldots \lstinline@)@ \nonterm{compound-statement}
    3551 \rhs \lstinline@catchResume@ \lstinline@(@ \ldots \lstinline@)@ \nonterm{compound-statement}
    3552 \rhs \nonterm{handler-clause} \lstinline@catchResume@ \lstinline@(@ \ldots \lstinline@)@ \nonterm{compound-statement}
     3501\rhs ©catch© ©(© \ldots ©)© \nonterm{compound-statement}
     3502\rhs \nonterm{handler-clause} ©catch© ©(© \ldots ©)© \nonterm{compound-statement}
     3503\rhs ©catchResume© ©(© \ldots ©)© \nonterm{compound-statement}
     3504\rhs \nonterm{handler-clause} ©catchResume© ©(© \ldots ©)© \nonterm{compound-statement}
    35533505\lhs{handler-clause}
    3554 \rhs \lstinline@catch@ \lstinline@(@ \nonterm{exception-declaration} \lstinline@)@ \nonterm{compound-statement}
    3555 \rhs \nonterm{handler-clause} \lstinline@catch@ \lstinline@(@ \nonterm{exception-declaration} \lstinline@)@ \nonterm{compound-statement}
    3556 \rhs \lstinline@catchResume@ \lstinline@(@ \nonterm{exception-declaration} \lstinline@)@ \nonterm{compound-statement}
    3557 \rhs \nonterm{handler-clause} \lstinline@catchResume@ \lstinline@(@ \nonterm{exception-declaration} \lstinline@)@ \nonterm{compound-statement}
     3506\rhs ©catch© ©(© \nonterm{exception-declaration} ©)© \nonterm{compound-statement}
     3507\rhs \nonterm{handler-clause} ©catch© ©(© \nonterm{exception-declaration} ©)© \nonterm{compound-statement}
     3508\rhs ©catchResume© ©(© \nonterm{exception-declaration} ©)© \nonterm{compound-statement}
     3509\rhs \nonterm{handler-clause} ©catchResume© ©(© \nonterm{exception-declaration} ©)© \nonterm{compound-statement}
    35583510\lhs{finally-clause}
    3559 \rhs \lstinline@finally@ \nonterm{compound-statement}
     3511\rhs ©finally© \nonterm{compound-statement}
    35603512\lhs{exception-declaration}
    35613513\rhs \nonterm{type-specifier}
     
    35653517\rhs \nonterm{new-abstract-declarator-tuple}
    35663518\lhs{asynchronous-statement}
    3567 \rhs \lstinline@enable@ \nonterm{identifier-list} \nonterm{compound-statement}
    3568 \rhs \lstinline@disable@ \nonterm{identifier-list} \nonterm{compound-statement}
     3519\rhs ©enable© \nonterm{identifier-list} \nonterm{compound-statement}
     3520\rhs ©disable© \nonterm{identifier-list} \nonterm{compound-statement}
    35693521\end{syntax}
    35703522
     
    35743526\subsubsection[The try statement]{The \lstinline@try@ statement}
    35753527
    3576 The \lstinline@try@ statement is a block with associated handlers, called a \Index{guarded block};
     3528The ©try© statement is a block with associated handlers, called a \Index{guarded block};
    35773529all other blocks are \Index{unguarded block}s.
    3578 A \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.
     3530A ©goto©, ©break©, ©return©, or ©continue© statement can be used to transfer control out of a try block or handler, but not into one.
    35793531
    35803532
    35813533\subsubsection[The enable/disable statements]{The \lstinline@enable@/\lstinline@disable@ statements}
    35823534
    3583 The \lstinline@enable@/\lstinline@disable@ statements toggle delivery of \Index{asynchronous exception}s.
     3535The ©enable©/©disable© statements toggle delivery of \Index{asynchronous exception}s.
    35843536
    35853537
     
    35913543\subsection{Predefined macro names}
    35923544
    3593 The implementation shall define the macro names \lstinline@__LINE__@, \lstinline@__FILE__@,
    3594 \lstinline@__DATE__@, and \lstinline@__TIME__@, as in the {\c11} standard.
    3595 It shall not define the macro name \lstinline@__STDC__@.
    3596 
    3597 In addition, the implementation shall define the macro name \lstinline@__CFORALL__@ to be the decimal constant 1.
     3545The implementation shall define the macro names ©__LINE__©, ©__FILE__©, ©__DATE__©, and ©__TIME__©, as in the {\c11} standard.
     3546It shall not define the macro name ©__STDC__©.
     3547
     3548In addition, the implementation shall define the macro name ©__CFORALL__© to be the decimal constant 1.
    35983549
    35993550
     
    36123563The pointer, integral, and floating-point types are all \define{scalar types}.
    36133564All of these types can be logically negated and compared.
    3614 The assertion ``\lstinline@scalar( Complex )@'' should be read as ``type \lstinline@Complex@ is scalar''.
     3565The assertion ``©scalar( Complex )©'' should be read as ``type ©Complex© is scalar''.
    36153566\begin{lstlisting}
    36163567trait scalar( otype T ) {§\impl{scalar}§
     
    36303581\end{lstlisting}
    36313582
    3632 The various flavors of \lstinline@char@ and \lstinline@int@ and the enumerated types make up the
     3583The various flavors of ©char© and ©int© and the enumerated types make up the
    36333584\define{integral types}.
    36343585\begin{lstlisting}
     
    36643615
    36653616Modifiable arithmetic lvalues are both modifiable scalar lvalues and arithmetic.
    3666 Note that this results in the ``inheritance'' of \lstinline@scalar@ along both paths.
     3617Note that this results in the ``inheritance'' of ©scalar© along both paths.
    36673618\begin{lstlisting}
    36683619trait m_l_arithmetic( otype T | m_l_scalar( T ) | arithmetic( T ) ) {§\impl{m_l_arithmetic}§
     
    36793630\subsection{Pointer and array types}
    36803631
    3681 Array types can barely be said to exist in {\c11}, since in most cases an array name is treated as a constant pointer to the first element of the array, and the subscript expression
    3682 ``\lstinline@a[i]@'' is equivalent to the dereferencing expression ``\lstinline@(*( a+( i )))@''.
    3683 Technically, pointer arithmetic and pointer comparisons other than ``\lstinline@==@'' and
    3684 ``\lstinline@!=@'' are only defined for pointers to array elements, but the type system does not enforce those restrictions.
     3632Array types can barely be said to exist in {\c11}, since in most cases an array name is treated as a constant pointer to the first element of the array, and the subscript expression ``©a[i]©'' is equivalent to the dereferencing expression ``©(*( a+( i )))©''.
     3633Technically, pointer arithmetic and pointer comparisons other than ``©==©'' and ``©!=©'' are only defined for pointers to array elements, but the type system does not enforce those restrictions.
    36853634Consequently, there is no need for a separate ``array type'' specification.
    36863635
    36873636Pointer types are scalar types.
    3688 Like other scalar types, they have ``\lstinline@+@'' and
    3689 ``\lstinline@-@'' operators, but the types do not match the types of the operations in
    3690 \lstinline@arithmetic@, so these operators cannot be consolidated in \lstinline@scalar@.
     3637Like other scalar types, they have ``©+©'' and ``©-©'' operators, but the types do not match the types of the operations in ©arithmetic©, so these operators cannot be consolidated in ©scalar©.
    36913638\begin{lstlisting}
    36923639trait pointer( type P | scalar( P ) ) {§\impl{pointer}§§\use{scalar}§
     
    37033650Specifications that define the dereference operator ( or subscript operator ) require two parameters, one for the pointer type and one for the pointed-at ( or element ) type.
    37043651Different specifications are needed for each set of \Index{type qualifier}s, because qualifiers are not included in types.
    3705 The assertion ``\lstinline@|ptr_to( Safe_pointer, int )@'' should be read as
    3706 ``\lstinline@Safe_pointer@ acts like a pointer to \lstinline@int@''.
     3652The assertion ``©|ptr_to( Safe_pointer, int )©'' should be read as ``©Safe_pointer© acts like a pointer to ©int©''.
    37073653\begin{lstlisting}
    37083654trait ptr_to( otype P | pointer( P ), otype T ) {§\impl{ptr_to}§§\use{pointer}§
     
    37243670\end{lstlisting}
    37253671
    3726 Assignment to pointers is more complicated than is the case with other types, because the target's type can have extra type qualifiers in the pointed-at type: a ``\lstinline@T *@'' can be assigned to a ``\lstinline@const T *@'', a ``\lstinline@volatile T *@'', and a ``\lstinline@const volatile T *@''.
    3727 Again, the pointed-at type is passed in, so that assertions can connect these specifications to the
    3728 ``\lstinline@ptr_to@'' specifications.
     3672Assignment to pointers is more complicated than is the case with other types, because the target's type can have extra type qualifiers in the pointed-at type: a ``©T *©'' can be assigned to a ``©const T *©'', a ``©volatile T *©'', and a ``©const volatile T *©''.
     3673Again, the pointed-at type is passed in, so that assertions can connect these specifications to the ``©ptr_to©'' specifications.
    37293674\begin{lstlisting}
    37303675trait m_l_ptr_to( otype P | m_l_pointer( P ),§\use{m_l_pointer}§§\impl{m_l_ptr_to}§ otype T | ptr_to( P, T )§\use{ptr_to}§ {
     
    37553700};
    37563701\end{lstlisting}
    3757 The assertion ``\lstinline@| m_l_ptr_like( Safe_ptr, const int * )@'' should be read as
    3758 ``\lstinline@Safe_ptr@ is a pointer type like \lstinline@const int *@''.
    3759 This specification has two defects, compared to the original four: there is no automatic assertion that dereferencing a
    3760 \lstinline@MyP@ produces an lvalue of the type that \lstinline@CP@ points at, and the
    3761 ``\lstinline@|m_l_pointer( CP )@'' assertion provides only a weak assurance that the argument passed to \lstinline@CP@ really is a pointer type.
     3702The assertion ``©| m_l_ptr_like( Safe_ptr, const int * )©'' should be read as ``©Safe_ptr© is a pointer type like ©const int *©''.
     3703This specification has two defects, compared to the original four: there is no automatic assertion that dereferencing a ©MyP© produces an lvalue of the type that ©CP© points at, and the ``©|m_l_pointer( CP )©'' assertion provides only a weak assurance that the argument passed to ©CP© really is a pointer type.
    37623704
    37633705
     
    37653707
    37663708Different operators often have related meanings;
    3767 for instance, in C, ``\lstinline@+@'',
    3768 ``\lstinline@+=@'', and the two versions of ``\lstinline@++@'' perform variations of addition.
     3709for instance, in C, ``©+©'', ``©+=©'', and the two versions of ``©++©'' perform variations of addition.
    37693710Languages like {\CC} and Ada allow programmers to define operators for new types, but do not require that these relationships be preserved, or even that all of the operators be implemented.
    37703711Completeness and consistency is left to the good taste and discretion of the programmer.
     
    37793720The different comparison operators have obvious relationships, but there is no obvious subset of the operations to use in the implementation of the others.
    37803721However, it is usually convenient to implement a single comparison function that returns a negative integer, 0, or a positive integer if its first argument is respectively less than, equal to, or greater than its second argument;
    3781 the library function \lstinline@strcmp@ is an example.
    3782 
    3783 C and \CFA have an extra, non-obvious comparison operator: ``\lstinline@!@'', logical negation, returns 1 if its operand compares equal to 0, and 0 otherwise.
     3722the library function ©strcmp© is an example.
     3723
     3724C and \CFA have an extra, non-obvious comparison operator: ``©!©'', logical negation, returns 1 if its operand compares equal to 0, and 0 otherwise.
    37843725\begin{lstlisting}
    37853726trait comparable( otype T ) {
     
    38293770\end{lstlisting}
    38303771
    3831 Note that, although an arithmetic type would certainly provide comparison functions, and an integral type would provide arithmetic operations, there does not have to be any relationship among
    3832 \lstinline@int_base@, \lstinline@arith_base@ and \lstinline@comparable@.
     3772Note that, although an arithmetic type would certainly provide comparison functions, and an integral type would provide arithmetic operations, there does not have to be any relationship among ©int_base©, ©arith_base© and ©comparable©.
    38333773Note also that these declarations provide guidance and assistance, but they do not define an absolutely minimal set of requirements.
    3834 A truly minimal implementation of an arithmetic type might only provide \lstinline@0@, \lstinline@1@, and \lstinline@?-=?@, which would be used by polymorphic \lstinline@?+=?@, \lstinline@?*=?@, and \lstinline@?/=?@ functions.
    3835 
    3836 Note also that \lstinline@short@ is an integer type in C11 terms, but has no operations!
     3774A truly minimal implementation of an arithmetic type might only provide ©0©, ©1©, and ©?-=?©, which would be used by polymorphic ©?+=?©, ©?*=?©, and ©?/=?© functions.
     3775
     3776Note also that ©short© is an integer type in C11 terms, but has no operations!
    38373777
    38383778
     
    38413781
    38423782Restrict allowed to qualify anything, or type/dtype parameters, but only affects pointers.
    3843 This gets into \lstinline@noalias@ territory.
    3844 Qualifying anything (``\lstinline@short restrict rs@'') means pointer parameters of \lstinline@?++@, etc, would need restrict qualifiers.
     3783This gets into ©noalias© territory.
     3784Qualifying anything (``©short restrict rs©'') means pointer parameters of ©?++©, etc, would need restrict qualifiers.
    38453785
    38463786Enumerated types.
     
    38523792Color, enum Color ) really make sense? ?++ does, but it adds (int)1.
    38533793
    3854 Operators on {,signed,unsigned} char and other small types. \lstinline@?<?@ harmless;
     3794Operators on {,signed,unsigned} char and other small types. ©?<?© harmless;
    38553795?*? questionable for chars.
    38563796Generic selections make these choices visible.
    3857 Safe conversion operators? Predefined
    3858 ``promotion'' function?
    3859 
    3860 \lstinline@register@ assignment might be handled as assignment to a temporary with copying back and forth, but copying must not be done by assignment.
    3861 
    3862 Don't use \lstinline@ptrdiff_t@ by name in the predefineds.
     3797Safe conversion operators? Predefined ``promotion'' function?
     3798
     3799©register© assignment might be handled as assignment to a temporary with copying back and forth, but copying must not be done by assignment.
     3800
     3801Don't use ©ptrdiff_t© by name in the predefineds.
    38633802
    38643803Polymorphic objects.
Note: See TracChangeset for help on using the changeset viewer.