Changeset 0638c44 for doc/refrat
 Timestamp:
 May 3, 2016, 9:30:55 AM (7 years ago)
 Branches:
 aaronthesis, armeh, cleanupdtors, ctor, deferred_resn, demangler, enum, forallpointerdecay, gc_noraii, jacob/cs343translation, jenkinssandbox, master, memory, newast, newastuniqueexpr, newenv, no_list, persistentindexer, pthreademulation, qualifiedEnum, resolvnew, with_gc
 Children:
 7937abf, a1d6d80
 Parents:
 e945826
 File:

 1 edited
Legend:
 Unmodified
 Added
 Removed

doc/refrat/refrat.tex
re945826 r0638c44 1 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% * Mode: Latex * %%%%%%%%%%%%%%%%%%%%%%%%%%%% 2 %% 1 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% * Mode: Latex * %%%%%%%%%%%%%%%%%%%%%%%%%%%%``%% 3 2 %% Cforall Version 1.0.0 Copyright (C) 2016 University of Waterloo 4 3 %% … … 11 10 %% Created On : Wed Apr 6 14:52:25 2016 12 11 %% Last Modified By : Peter A. Buhr 13 %% Last Modified On : Sat Apr 30 13:45:40201614 %% Update Count : 2912 %% Last Modified On : Tue May 3 09:23:43 2016 13 %% Update Count : 52 15 14 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 16 15 17 16 % requires tex packages: texlivebase texlivelatexbase texcommon texlivehumanities texlivelatexextra texlivefontsrecommended 18 17 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: Cq M) 19 % red highlighting ®...® (registered trademark sumbol) emacs: Cq M. 20 % latex escape §...§ (section symbol) emacs: Cq M' 21 % keyword escape ¶...¶ (pilcrow symbol) emacs: Cq M^ 23 22 % math escape $...$ (dollar symbol) 24 23 … … 27 26 28 27 % 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} 29 32 \usepackage{fullpage,times} 33 \usepackage{epic,eepic} 30 34 \usepackage{xspace} 31 35 \usepackage{varioref} … … 47 51 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 48 52 53 % Names used in the document. 54 55 \newcommand{\Version}{1.0.0} 56 57 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 58 49 59 \setcounter{secnumdepth}{3} % number subsubsections 50 60 \setcounter{tocdepth}{3} % subsubsections in table of contents … … 131 141 \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 132 142 \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 pointedat 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; 143 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 pointedat 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. 144 The outer declaration becomes \Index{visible} when the scope of the inner declaration terminates. 145 \begin{rationale} 146 Hence, a \CFA program can declare an ©int v© and a ©float v© in the same scope; 138 147 a {\CC} program can not. 139 148 \end{rationale} … … 149 158 Identifiers with \Index{no linkage} always denote unique entities. 150 159 \begin{rationale} 151 A \CFA program can declare an \lstinline@extern int v@ and an \lstinline@extern float v@;160 A \CFA program can declare an ©extern int v© and an ©extern float v©; 152 161 a C program cannot. 153 162 \end{rationale} … … 172 181 \end{lstlisting} 173 182 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@.183 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., ©sumable©. 175 184 The instantiation then has the semantics that would result if the type parameters were substituted into the type generator declaration by macro substitution. 176 185 … … 233 242 In \CFA, these conversions play a role in overload resolution, and collectively are called the \define{safe arithmetic conversion}s. 234 243 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{ranksee{integer conversion rank}} $r$.236 Let \lstinline@unsigned$_{mr}$@be the unsigned integer type with maximal rank.244 Let ©int$_r$© and ©unsigned$_r$© be the signed and unsigned integer types with integer conversion rank\index{integer conversion rank}\index{ranksee{integer conversion rank}} $r$. 245 Let ©unsigned$_{mr}$© be the unsigned integer type with maximal rank. 237 246 238 247 The following conversions are \emph{direct} safe arithmetic conversions. … … 241 250 The \Index{integer promotion}s. 242 251 \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@.252 For every rank $r$ greater than or equal to the rank of ©int©, conversion from ©int$_r$© to ©unsigned$_r$©. 253 \item 254 For 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 256 Conversion from ©unsigned$_{mr}$© to ©float©. 248 257 \item 249 258 Conversion from an enumerated type to its compatible integer type. 250 259 \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@.260 Conversion from ©float© to ©double©, and from ©double© to ©long double©. 261 \item 262 Conversion from ©float _Complex© to ©double _Complex©, and from ©double _Complex© to ©long double _Complex©. 254 263 \begin{sloppypar} 255 264 \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.265 Conversion from ©float _Imaginary© to ©double _Imaginary©, and from ©double _Imaginary© to ©long double _Imaginary©, if the implementation supports imaginary types. 257 266 \end{sloppypar} 258 267 \end{itemize} 259 268 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.269 If 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. 261 270 262 271 \begin{rationale} … … 291 300 move_to( &cp1, &cp2 ); 292 301 \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. 302 Thanks to implicit conversion, the two arguments that ©move_by()© receives are pointers to ©cp1©'s second member and ©cp2©'s second member. 295 303 296 304 … … 334 342 a direct safe arithmetic conversion; 335 343 \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@;344 from any object type or incomplete type to ©void©; 345 \item 346 from a pointer to any non©void© type to a pointer to ©void©; 339 347 \item 340 348 from a pointer to any type to a pointer to a more qualified version of the type\index{qualified type}; … … 347 355 Conversions that are not safe conversions are \define{unsafe conversion}s. 348 356 \begin{rationale} 349 As in C, there is an implicit conversion from \lstinline@void *@to any pointer type.357 As in C, there is an implicit conversion from ©void *© to any pointer type. 350 358 This is clearly dangerous, and {\CC} does not have this implicit conversion. 351 359 \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. … … 373 381 \begin{itemize} 374 382 \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. 383 The cost of an implicit conversion from ©int© to ©long© is 1. 384 The 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 387 If ©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©. 388 Otherwise, ©unsigned short© is converted directly to ©unsigned©, and the cost is 1. 389 390 \item 391 If ©long© can represent all the values of ©unsigned©, then the conversion cost of ©unsigned© to ©long© is 1. 385 392 Otherwise, the conversion is an unsafe conversion, and its conversion cost is undefined. 386 393 \end{itemize} … … 390 397 \begin{syntax} 391 398 \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© 398 405 \end{syntax} 399 406 … … 402 409 403 410 \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 programmerdefined data types as well), so \CFA treats them as overloadable identifiers.411 Furthermore, the constants ``©0©'' and ``©1©'' have special status for many of C's data types (and for many programmerdefined data types as well), so \CFA treats them as overloadable identifiers. 405 412 Programmers can use these identifiers to declare functions and objects that implement operators and constants for their own types. 406 413 … … 411 418 \begin{syntax} 412 419 \oldlhs{identifier} 413 \rhs \lstinline@0@414 \rhs \lstinline@1@420 \rhs ©0© 421 \rhs ©1© 415 422 \end{syntax} 416 423 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. 418 425 No other tokens defined by the rules for integer constants are considered to be identifiers. 419 426 \begin{rationale} 420 Why `` \lstinline@0@'' and ``\lstinline@1@''? Those integers have special status in C.427 Why ``©0©'' and ``©1©''? Those integers have special status in C. 421 428 All 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.429 The operations ``©&&©'', ``©©'', and ``©!©'' can be applied to any scalar arguments, and are defined in terms of comparison against 0. 423 430 A \nonterm{constantexpression} that evaluates to 0 is effectively compatible with every pointer type. 424 431 425 432 In 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. 426 433 However, userdefined 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 userdefined pointerlike types may need a null value. 427 Defining special constants for a userdefined 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 instancewould not be much of an improvement.434 Defining special constants for a userdefined type is more efficient than defining a conversion to the type from ©_Bool©. 435 436 Why \emph{just} ``©0©'' and ``©1©''? Why not other integers? No other integers have special status in C. 437 A facility that let programmers declare specific constants``©const Rational 12©'', for instancewould not be much of an improvement. 431 438 Some facility for defining the creation of values of programmerdefined types from arbitrary integer tokens would be needed. 432 439 The complexity of such a feature doesn't seem worth the gain. … … 444 451 \begin{tabular}[t]{ll} 445 452 %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{?/?}\\ 459 466 \end{tabular}\hfil 460 467 \begin{tabular}[t]{ll} 461 468 %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{?&?}\\ 474 481 \end{tabular}\hfil 475 482 \begin{tabular}[t]{ll} 476 483 %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@?<<=?@& leftshift assignment \impl{?<<=?}\\486 \lstinline@?>>=?@& rightshift 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 ©?<<=?© & leftshift assignment \impl{?<<=?}\\ 493 ©?>>=?© & rightshift assignment \impl{?>>=?}\\ 494 ©?&=?© & bitwise AND assignment \impl{?&=?}\\ 495 ©?^=?© & exclusive OR assignment \impl{?^=?}\\ 496 ©?=?© & inclusive OR assignment \impl{?"=?}\\ 490 497 \end{tabular} 491 498 \hfil … … 502 509 503 510 \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 a505 \CFA compiler detects a syntax error because it treats `` \lstinline@?@'' as an identifier, not as the two tokens ``\lstinline@?@'' and ``\lstinline@@''.511 The 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 ``©©''. 506 513 \end{rationale} 507 514 … … 510 517 \begin{itemize} 511 518 \item 512 The logical operators ``\lstinline@&&@'' and ``\lstinline@@'', and the conditional operator 513 ``\lstinline@?:@''. 519 The logical operators ``©&&©'' and ``©©'', and the conditional operator ``©?:©''. 514 520 These operators do not always evaluate their operands, and hence can not be properly defined by functions unless some mechanism like callbyname 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 userdefined types is enough to allow them to be used in logical expressions.521 Note that the definitions of ``©&&©'' and ``©©'' say that they work by checking that their arguments are unequal to 0, so defining ``©!=©'' and ``©0©'' for userdefined types is enough to allow them to be used in logical expressions. 516 522 517 523 \item … … 522 528 \item 523 529 The ``address of'' operator. 524 It would seem useful to define a unary `` \lstinline@&@'' operator that returns values of some programmerdefined pointerlike type.530 It would seem useful to define a unary ``©&©'' operator that returns values of some programmerdefined pointerlike type. 525 531 The 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 programmerdefined 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 pointerlike 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 )@'' 532 Consider the expression ``©p = &x©'', where ©x© is of type ©T© and ©p© has the programmerdefined type ©T_ptr©. 533 The expression might be treated as a call to the unary function ``©&?©''. 534 Now 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 pointerlike result from a value. 535 Hence the parameter must have type ©T *©. 536 But then the expression must be rewritten as ``©p = &?( &x )©'' 532 537 which doesn't seem like progress! 533 538 534 539 The rule for addressof expressions would have to be something like ``keep applying addressof functions until you get one that takes a pointer argument, then use the builtin 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.540 It seems simpler to define a conversion function from ©T *© to ©T_ptr©. 541 542 \item 543 The ©sizeof© operator. 539 544 It is already defined for every object type, and intimately tied into the language's storage allocation model. 540 545 Redefining it seems pointless. 541 546 542 547 \item 543 The ``member of'' operators `` \lstinline@.@'' and ``\lstinline@>@''.548 The ``member of'' operators ``©.©'' and ``©>©''. 544 549 These are not really infix operators, since their right ``operand'' is not a value or object. 545 550 … … 578 583 The ``fewest unsafe conversions'' rule ensures that the usual conversions are done, if possible. 579 584 The ``lowest total expression cost'' rule chooses the proper common type. 580 The oddlooking ``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@.585 The oddlooking ``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©. 581 586 582 587 The ``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}). 588 It also gives preference to monomorphic values (such as the ©int© ©0©) over polymorphic values (such as the \Index{null pointer} ©0©\use{0}). 586 589 However, interpretations that call polymorphic functions are preferred to interpretations that perform unsafe conversions, because those conversions potentially lose accuracy or violate strong typing. 587 590 … … 603 606 \begin{rationale} 604 607 Predefined functions and constants have internal linkage because that simplifies optimization in traditional compileandlink environments. 605 For instance, `` \lstinline@an_int + an_int@'' is equivalent to ``\lstinline@?+?(an_int, an_int)@''.608 For instance, ``©an_int + an_int©'' is equivalent to ``©?+?(an_int, an_int)©''. 606 609 If integer addition has not been redefined in the current scope, a compiler can generate code to perform the addition directly. 607 610 If predefined functions had external linkage, this optimization would be difficult. … … 629 632 \rhs \nonterm{constant} 630 633 \rhs \nonterm{stringliteral} 631 \rhs \lstinline@(@ \nonterm{expression} \lstinline@)@634 \rhs ©(© \nonterm{expression} ©)© 632 635 \rhs \nonterm{genericselection} 633 636 \end{syntax} … … 645 648 646 649 A \nonterm{constant} or \nonterm{stringliteral} 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.650 The predefined integer identifiers ``©1©'' and ``©0©'' have the integer values 1 and 0, respectively. 651 The 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. 649 652 650 653 A parenthesised expression has the same interpretations as the contained \nonterm{expression}. 651 654 652 655 \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. 656 The 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 *©. 657 In each case, the null pointer conversion is better\index{best valid interpretations} than the unsafe conversion of the integer ©0© to a pointer. 656 658 657 659 \begin{rationale} … … 659 661 660 662 \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 663 The C token ``©0©'' is an expression of type ©int© with the value ``zero'', and it \emph{also} is a null pointer constant. 664 Similarly, ``©(void *)0© is an expression of type ©(void *)© whose value is a null pointer, and it also is a null pointer constant. 665 However, in C, ``©(void *)(void *)0©'' is 665 666 \emph{not} a null pointer constant, even though it is nullvalued, a pointer, and constant! The semantics of C expressions contain many special cases to deal with subexpressions that are null pointer constants. 666 667 … … 669 670 \begin{lstlisting} 670 671 forall( 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} pointertoobject type or pointertoincomplete type.672 \end{lstlisting} means that ©0© is a polymorphic object, and contains a value that can have \emph{any} pointertoobject type or pointertoincomplete type. 672 673 The only such value is the null pointer. 673 674 Therefore the type \emph{alone} is enough to identify a null pointer. … … 679 680 680 681 \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.682 If 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. 682 683 683 684 \semantics … … 690 691 \lhs{postfixexpression} 691 692 \rhs \nonterm{primaryexpression} 692 \rhs \nonterm{postfixexpression} \lstinline@[@ \nonterm{expression} \lstinline@]@693 \rhs \nonterm{postfixexpression} \lstinline@(@694 \nonterm{argumentexpressionlist}\opt \lstinline@)@695 \rhs \nonterm{postfixexpression} \lstinline@.@\nonterm{identifier}696 \rhs \nonterm{postfixexpression} \lstinline@>@\nonterm{identifier}697 \rhs \nonterm{postfixexpression} \lstinline@++@698 \rhs \nonterm{postfixexpression} \lstinline@@699 \rhs \lstinline@(@ \nonterm{typename} \lstinline@)@ \lstinline@{@ \nonterm{initializerlist} \lstinline@}@700 \rhs \lstinline@(@ \nonterm{typename} \lstinline@)@ \lstinline@{@ \nonterm{initializerlist} \lstinline@,@ \lstinline@}@693 \rhs \nonterm{postfixexpression} ©[© \nonterm{expression} ©]© 694 \rhs \nonterm{postfixexpression} ©(© 695 \nonterm{argumentexpressionlist}\opt ©)© 696 \rhs \nonterm{postfixexpression} ©.© \nonterm{identifier} 697 \rhs \nonterm{postfixexpression} ©>© \nonterm{identifier} 698 \rhs \nonterm{postfixexpression} ©++© 699 \rhs \nonterm{postfixexpression} ©© 700 \rhs ©(© \nonterm{typename} ©)© ©{© \nonterm{initializerlist} ©}© 701 \rhs ©(© \nonterm{typename} ©)© ©{© \nonterm{initializerlist} ©,© ©}© 701 702 \lhs{argumentexpressionlist} 702 703 \rhs \nonterm{assignmentexpression} 703 \rhs \nonterm{argumentexpressionlist} \lstinline@,@704 \rhs \nonterm{argumentexpressionlist} ©,© 704 705 \nonterm{assignmentexpression} 705 706 \end{syntax} … … 739 740 The interpretations of subscript expressions are the interpretations of the corresponding function call expressions. 740 741 \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@?[?]@. 742 C 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 ©?[?]©. 743 743 744 744 Subscript expressions are rewritten as function calls that pass the first parameter by value. 745 745 This is somewhat unfortunate, since arraylike 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.746 The alternative is to use the rewrite rule ``©a[b]© \rewrite ©?[?](&(a), b)©''. 747 However, C semantics forbid this approach: the ©a© in ``©a[b]©'' can be an arbitrary pointer value, which does not have an address. 748 748 749 749 The repetitive form of the predefined identifiers shows up a deficiency\index{deficiencies!pointers … … 760 760 \nonterm{postfixexpression} in a function call may have some interpretations that are function designators and some that are not. 761 761 762 For those interpretations of the \nonterm{postfixexpression} that are not function designators, the expression is rewritten and becomes a call of a function named `` \lstinline@?()@''.762 For those interpretations of the \nonterm{postfixexpression} that are not function designators, the expression is rewritten and becomes a call of a function named ``©?()©''. 763 763 The valid interpretations of the rewritten expression are determined in the manner described below. 764 764 … … 767 767 \begin{itemize} 768 768 \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. 771 770 \end{itemize} 772 771 The type of the valid interpretation is the return type of the function designator. … … 776 775 \begin{itemize} 777 776 \item 778 If the declaration of the implicit parameter uses \Index{typeclass} \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.777 If the declaration of the implicit parameter uses \Index{typeclass} ©type©\use{type}, the implicit argument must be an object type; 778 if it uses ©dtype©, the implicit argument must be an object type or an incomplete type; 779 and if it uses ©ftype©, the implicit argument must be a function type. 781 780 782 781 \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. … … 797 796 \begin{rationale} 798 797 One 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@.798 For 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©. 800 799 801 800 \CFA\index{deficiencies!generalizability} does not fully possess this property, because … … 811 810 f = g( d, f ); // (3) (unsafe conversion to float) 812 811 \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. 812 If ©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 814 Another example is the function ``©void h( int *);©''. 815 This function can be passed a ©void *© argument, but the generalization ``©forall( otype T ) void h( T *);©'' can not. 816 In this case, ©void© is not a valid value for ©T© because it is not an object type. 817 If unsafe conversions were allowed, ©T© could be inferred to be \emph{any} object type, which is undesirable. 821 818 \end{rationale} 822 819 823 820 \examples 824 A function called `` \lstinline@?()@'' might be part of a numerical differentiation package.821 A function called ``©?()©'' might be part of a numerical differentiation package. 825 822 \begin{lstlisting} 826 823 extern otype Derivative; … … 833 830 d = sin_dx( 12.9 ); 834 831 \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 )@''.832 Here, the only interpretation of ©sin_dx© is as an object of type ©Derivative©. 833 For that interpretation, the function call is treated as ``©?()( sin_dx, 12.9 )©''. 837 834 \begin{lstlisting} 838 835 int f( long ); // (1) … … 841 838 int i = f( 5 ); // calls (1) 842 839 \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.840 Function (1) provides a valid interpretation of ``©f( 5 )©'', using an implicit ©int© to ©long© conversion. 841 The 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. 845 842 846 843 \begin{lstlisting} … … 848 845 double d = h( 1.5 ); 849 846 \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©. 852 848 853 849 \begin{lstlisting} 854 850 forall( otype T, otype U ) void g( T, U ); // (4) 855 851 forall( otype T ) void g( T, T ); // (5) 856 forall( otype T ) void g( T, long ); 852 forall( otype T ) void g( T, long ); // (6) 857 853 void g( long, long ); // (7) 858 854 double d; 859 855 int i; 860 856 int *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).857 g( d, d ); // calls (5) 858 g( d, i ); // calls (6) 859 g( i, i ); // calls (7) 860 g( i, p ); // calls (4) 861 \end{lstlisting} 862 The 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). 867 863 868 864 For 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.865 Of the remaining interpretations for (4), (5), and (6) (with ©i© converted to ©long©), (6) is chosen because it is the least polymorphic. 870 866 871 867 The third call has valid interpretations for all of the functions; … … 883 879 shuffle( 9, 10 ); 884 880 \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) 881 The 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} 883 extern void q( int ); // (8) 884 extern void q( void * ); // (9) 890 885 extern void r(); 891 886 q( 0 ); 892 887 r( 0 ); 893 888 \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.889 The ©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). 890 The former is chosen because the ©int© ©0© is \Index{less polymorphic}. 891 For the same reason, ©int© ©0© is passed to ©r()©, even though it has \emph{no} declared parameter types. 897 892 898 893 899 894 \subsubsection{Structure and union members} 900 895 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©. 897 If 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. 898 If 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. 906 899 The expression has no other interpretations. 907 900 908 The expression `` \lstinline@p>m@'' has the same interpretations as the expression ``\lstinline@(*p).m@''.901 The expression ``©p>m©'' has the same interpretations as the expression ``©(*p).m©''. 909 902 910 903 … … 1001 994 * ?( _Atomic const restrict volatile T * _Atomic restrict volatile * ); 1002 995 \end{lstlisting} 1003 For every extended integer type \lstinline@X@there exist996 For every extended integer type ©X© there exist 1004 997 % Don't use predefined: keep this out of prelude.cf. 1005 998 \begin{lstlisting} … … 1007 1000 ?( volatile X * ), ?( _Atomic volatile X * ); 1008 1001 \end{lstlisting} 1009 For every complete enumerated type \lstinline@E@there exist1002 For every complete enumerated type ©E© there exist 1010 1003 % Don't use predefined: keep this out of prelude.cf. 1011 1004 \begin{lstlisting} … … 1015 1008 1016 1009 \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.1010 Note 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. 1018 1011 This partially enforces the C semantic rule that such operands must be \emph{modifiable} lvalues. 1019 1012 \end{rationale} … … 1021 1014 \begin{rationale} 1022 1015 In 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@.1016 Hence, ©void *© objects cannot be incremented. 1017 In \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©. 1025 1018 \end{rationale} 1026 1019 … … 1040 1033 \end{lstlisting} 1041 1034 \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. 1035 Since ©&(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 *©. 1037 Note that there is no conversion that adds an ©_Atomic© qualifier, so the ©_Atomic volatile short int© overloading does not provide a valid interpretation. 1046 1038 \end{sloppypar} 1047 1039 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.1040 There 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 1042 The 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. 1051 1043 \begin{lstlisting} 1052 1044 char * const restrict volatile * restrict volatile pqpc; … … 1055 1047 ppc++; 1056 1048 \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@.1049 Since ©&(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©. 1060 1052 1061 1053 \begin{rationale} … … 1071 1063 \begin{enumerate} 1072 1064 \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 by1065 ``©char * p; p++;©''. 1066 The argument to ©?++© has type ©char * *©, and the result has type ©char *©. 1067 The expression would be valid if ©?++© were declared by 1076 1068 \begin{lstlisting} 1077 1069 forall( 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++©''. 1074 The 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. 1083 1075 Hence the actual predefined function is 1084 1076 \begin{lstlisting} 1085 1077 forall( 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 constqualified, 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 constqualified, so constant pointers cannot be incremented.) 1079 1080 \item 1081 ``©char *_Atomic ap; ap++©''. 1082 The result again has type ©char *©, but no safe conversion adds an ©_Atomic© qualifier, so the function in point 2 is not applicable. 1083 A separate overloading of ©?++© is required. 1084 1085 \item 1086 ``©char const volatile * pq; pq++©''. 1087 Here the result has type ©char const volatile *©, so a new overloading is needed: 1098 1088 \begin{lstlisting} 1099 1089 forall( otype T ) T const volatile * ?++( T const volatile *restrict volatile * ); … … 1102 1092 1103 1093 \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++©''. 1095 The ©restrict© qualifier is handled just like ©const© and ©volatile© in the previous case: 1106 1096 \begin{lstlisting} 1107 1097 forall( 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 restrictqualified types to be pointertoobject types, and \lstinline@T@is not syntactically a pointer type. \CFA loosens the constraint.1098 \end{lstlisting} with ©T© inferred to be ©float *©. 1099 This looks odd, because {\c11} contains a constraint that requires restrictqualified types to be pointertoobject types, and ©T© is not syntactically a pointer type. \CFA loosens the constraint. 1110 1100 \end{enumerate} 1111 1101 \end{rationale} … … 1123 1113 \lhs{unaryexpression} 1124 1114 \rhs \nonterm{postfixexpression} 1125 \rhs \lstinline@++@\nonterm{unaryexpression}1126 \rhs \lstinline@@\nonterm{unaryexpression}1115 \rhs ©++© \nonterm{unaryexpression} 1116 \rhs ©© \nonterm{unaryexpression} 1127 1117 \rhs \nonterm{unaryoperator} \nonterm{castexpression} 1128 \rhs \lstinline@sizeof@\nonterm{unaryexpression}1129 \rhs \lstinline@sizeof@ \lstinline@(@ \nonterm{typename} \lstinline@)@1130 \lhs{unaryoperator} one of \rhs \lstinline@&@ \lstinline@*@ \lstinline@+@ \lstinline@@ \lstinline@~@ \lstinline@!@1118 \rhs ©sizeof© \nonterm{unaryexpression} 1119 \rhs ©sizeof© ©(© \nonterm{typename} ©)© 1120 \lhs{unaryoperator} one of \rhs ©&© ©*© ©+© ©© ©~© ©!© 1131 1121 \end{syntax} 1132 1122 … … 1235 1225 * ?( _Atomic const restrict volatile T * _Atomic restrict volatile * ); 1236 1226 \end{lstlisting} 1237 For every extended integer type \lstinline@X@there exist1227 For every extended integer type ©X© there exist 1238 1228 % Don't use predefined: keep this out of prelude.cf. 1239 1229 \begin{lstlisting} … … 1243 1233 ?( _Atomic volatile X * ); 1244 1234 \end{lstlisting} 1245 For every complete enumerated type \lstinline@E@there exist1235 For every complete enumerated type ©E© there exist 1246 1236 % Don't use predefined: keep this out of prelude.cf. 1247 1237 \begin{lstlisting} … … 1280 1270 1281 1271 \constraints 1282 The operand of the unary `` \lstinline@&@'' operator shall have exactly one1272 The operand of the unary ``©&©'' operator shall have exactly one 1283 1273 \Index{interpretation}\index{ambiguous interpretation}, which shall be unambiguous. 1284 1274 1285 1275 \semantics 1286 The ``\lstinline@&@'' expression has one interpretation which is of type \lstinline@T *@, where 1287 \lstinline@T@ is the type of the operand. 1276 The ``©&©'' expression has one interpretation which is of type ©T *©, where ©T© is the type of the operand. 1288 1277 1289 1278 The interpretations of an indirection expression are the interpretations of the corresponding function call. … … 1314 1303 forall( ftype FT ) int !?( FT * ); 1315 1304 \end{lstlisting} 1316 For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@there exist1305 For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist 1317 1306 % Don't use predefined: keep this out of prelude.cf. 1318 1307 \begin{lstlisting} … … 1330 1319 eat_double(li ); // §\rewrite§ eat_double( ?( li ) ); 1331 1320 \end{lstlisting} 1332 The valid interpretations of `` \lstinline@li@'' (assuming no extended integer types exist) are1321 The valid interpretations of ``©li©'' (assuming no extended integer types exist) are 1333 1322 \begin{center} 1334 1323 \begin{tabular}{llc} interpretation & result type & expression conversion cost \\ 1335 1324 \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) \\ 1348 1337 \end{tabular} 1349 1338 \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, are1339 The valid interpretations of the ©eat_double© call, with the cost of the argument conversion and the cost of the entire expression, are 1351 1340 \begin{center} 1352 1341 \begin{tabular}{lcc} interpretation & argument cost & expression cost \\ 1353 1342 \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) \\ 1366 1355 \end{tabular} 1367 1356 \end{center} 1368 Each has result type \lstinline@void@, so the best must be selected.1357 Each has result type ©void©, so the best must be selected. 1369 1358 The 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) )@. 1359 The remainder have equal expression conversion costs, so the ``highest argument conversion cost'' rule is invoked, and the chosen interpretation is ©eat_double( (double)?(li) )©. 1373 1360 1374 1361 … … 1376 1363 1377 1364 \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{typedeclaration} or a1365 The operand of ©sizeof© or ©_Alignof© shall not be ©type©, ©dtype©, or ©ftype©. 1366 1367 When 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 1369 When ©sizeof© is applied to an identifier declared by a \nonterm{typedeclaration} or a 1383 1370 \nonterm{typeparameter}, it yields the size in bytes of the type that implements the operand. 1384 1371 When the operand is an opaque type or an inferred type parameter\index{inferred parameter}, the expression is not a constant expression. 1385 1372 1386 When \lstinline@_Alignof@is applied to an identifier declared by a \nonterm{typedeclaration} or a1373 When ©_Alignof© is applied to an identifier declared by a \nonterm{typedeclaration} or a 1387 1374 \nonterm{typeparameter}, it yields the alignment requirement of the type that implements the operand. 1388 1375 When the operand is an opaque type or an inferred type parameter\index{inferred parameter}, the expression is not a constant expression. … … 1398 1385 } 1399 1386 \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. 1388 Within ©f()©, ``©sizeof(T)©'' is fixed for each call of ©f()©, but may vary from call to call. 1403 1389 \end{rationale} 1404 1390 … … 1409 1395 \lhs{castexpression} 1410 1396 \rhs \nonterm{unaryexpression} 1411 \rhs \lstinline@(@ \nonterm{typename} \lstinline@)@\nonterm{castexpression}1397 \rhs ©(© \nonterm{typename} ©)© \nonterm{castexpression} 1412 1398 \end{syntax} 1413 1399 1414 1400 \constraints 1415 The \nonterm{typename} in a \nonterm{castexpression} shall not be \lstinline@type@, 1416 \lstinline@dtype@, or \lstinline@ftype@. 1401 The \nonterm{typename} in a \nonterm{castexpression} shall not be ©type©, ©dtype©, or ©ftype©. 1417 1402 1418 1403 \semantics 1419 1404 1420 In a \Index{cast expression} `` \lstinline@(@\nonterm{typename}\lstinline@)e@'', if1421 \nonterm{typename} 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{typename}, and the interpretation of the cast expression is the cast of the interpretation that can be converted at the lowest cost.1405 In a \Index{cast expression} ``©(©\nonterm{typename}©)e©'', if 1406 \nonterm{typename} is the type of an interpretation of ©e©, then that interpretation is the only interpretation of the cast expression; 1407 otherwise, ©e© shall have some interpretation that can be converted to \nonterm{typename}, and the interpretation of the cast expression is the cast of the interpretation that can be converted at the lowest cost. 1423 1408 The 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. 1424 1409 … … 1433 1418 \lhs{multiplicativeexpression} 1434 1419 \rhs \nonterm{castexpression} 1435 \rhs \nonterm{multiplicativeexpression} \lstinline@*@\nonterm{castexpression}1436 \rhs \nonterm{multiplicativeexpression} \lstinline@/@\nonterm{castexpression}1437 \rhs \nonterm{multiplicativeexpression} \lstinline@%@\nonterm{castexpression}1420 \rhs \nonterm{multiplicativeexpression} ©*© \nonterm{castexpression} 1421 \rhs \nonterm{multiplicativeexpression} ©/© \nonterm{castexpression} 1422 \rhs \nonterm{multiplicativeexpression} ©%© \nonterm{castexpression} 1438 1423 \end{syntax} 1439 1424 … … 1469 1454 ?*?( _Complex long double, _Complex long double ), ?/?( _Complex long double, _Complex long double ); 1470 1455 \end{lstlisting} 1471 For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@there exist1456 For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist 1472 1457 % Don't use predefined: keep this out of prelude.cf. 1473 1458 \begin{lstlisting} … … 1490 1475 eat_double( li % i ); 1491 1476 \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 ) are1477 ``©li % i©'' is rewritten as ``©?%?(li, i )©''. 1478 The 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 1494 1479 \begin{center} 1495 1480 \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 \\ 1503 1488 \end{tabular} 1504 1489 \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 )@''. 1490 The 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©. 1494 If ©s© is a ©short int©, ``©s *s©'' does not have type ©short int©; 1495 it is treated as ``©( (int)s ) * ( (int)s )©'', and has type ©int©. \CFA matches that pattern; 1496 it does not predefine ``©short ?*?( short, short )©''. 1513 1497 1514 1498 These ``missing'' operators limit polymorphism. … … 1519 1503 square( s ); 1520 1504 \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@. 1505 Since \CFA does not define a multiplication operator for ©short int©, ©square( s )© is treated as ©square( (int)s )©, and the result has type ©int©. 1524 1506 This is mildly surprising, but it follows the {\c11} operator pattern. 1525 1507 … … 1530 1512 product( sa, 5); 1531 1513 \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@''. 1514 This has no valid interpretations, because \CFA has no conversion from ``array of ©short int©'' to ``array of ©int©''. 1534 1515 The alternatives in such situations include 1535 1516 \begin{itemize} 1536 1517 \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. 1518 Defining monomorphic overloadings of ©product© for ©short© and the other ``small'' types. 1519 \item 1520 Defining ``©short ?*?( short, short )©'' within the scope containing the call to ©product©. 1521 \item 1522 Defining ©product© to take as an argument a conversion function from the ``small'' type to the operator's argument type. 1544 1523 \end{itemize} 1545 1524 \end{rationale} … … 1551 1530 \lhs{additiveexpression} 1552 1531 \rhs \nonterm{multiplicativeexpression} 1553 \rhs \nonterm{additiveexpression} \lstinline@+@\nonterm{multiplicativeexpression}1554 \rhs \nonterm{additiveexpression} \lstinline@@\nonterm{multiplicativeexpression}1532 \rhs \nonterm{additiveexpression} ©+© \nonterm{multiplicativeexpression} 1533 \rhs \nonterm{additiveexpression} ©© \nonterm{multiplicativeexpression} 1555 1534 \end{syntax} 1556 1535 … … 1611 1590 * ??( _Atomic const restrict volatile T *, _Atomic const restrict volatile T * ); 1612 1591 \end{lstlisting} 1613 For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@there exist1592 For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist 1614 1593 % Don't use predefined: keep this out of prelude.cf. 1615 1594 \begin{lstlisting} … … 1621 1600 1622 1601 \begin{rationale} 1623 \lstinline@ptrdiff_t@ is an implementationdefined 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 implementationdefined identifier defined in ©<stddef.h>© that is synonymous with a signed integral type that is large enough to hold the difference between two pointers. 1624 1603 It 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.1604 The {\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. 1626 1605 \end{rationale} 1627 1606 … … 1632 1611 \lhs{shiftexpression} 1633 1612 \rhs \nonterm{additiveexpression} 1634 \rhs \nonterm{shiftexpression} \lstinline@<<@\nonterm{additiveexpression}1635 \rhs \nonterm{shiftexpression} \lstinline@>>@\nonterm{additiveexpression}1613 \rhs \nonterm{shiftexpression} ©<<© \nonterm{additiveexpression} 1614 \rhs \nonterm{shiftexpression} ©>>© \nonterm{additiveexpression} 1636 1615 \end{syntax} 1637 1616 … … 1651 1630 long long unsigned int ?<<?( long long unsigned int, int ), ?>>?( long long unsigned int, int); 1652 1631 \end{lstlisting} 1653 For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@there exist1632 For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist 1654 1633 % Don't use predefined: keep this out of prelude.cf. 1655 1634 \begin{lstlisting} … … 1671 1650 \lhs{relationalexpression} 1672 1651 \rhs \nonterm{shiftexpression} 1673 \rhs \nonterm{relationalexpression} \lstinline@< @\nonterm{shiftexpression}1674 \rhs \nonterm{relationalexpression} \lstinline@> @\nonterm{shiftexpression}1675 \rhs \nonterm{relationalexpression} \lstinline@<=@\nonterm{shiftexpression}1676 \rhs \nonterm{relationalexpression} \lstinline@>=@\nonterm{shiftexpression}1652 \rhs \nonterm{relationalexpression} ©< © \nonterm{shiftexpression} 1653 \rhs \nonterm{relationalexpression} ©> © \nonterm{shiftexpression} 1654 \rhs \nonterm{relationalexpression} ©<=© \nonterm{shiftexpression} 1655 \rhs \nonterm{relationalexpression} ©>=© \nonterm{shiftexpression} 1677 1656 \end{syntax} 1678 1657 … … 1714 1693 ?>=?( _Atomic const restrict volatile DT *, _Atomic const restrict volatile DT * ); 1715 1694 \end{lstlisting} 1716 For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@there exist1695 For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist 1717 1696 % Don't use predefined: keep this out of prelude.cf. 1718 1697 \begin{lstlisting} … … 1732 1711 \lhs{equalityexpression} 1733 1712 \rhs \nonterm{relationalexpression} 1734 \rhs \nonterm{equalityexpression} \lstinline@==@\nonterm{relationalexpression}1735 \rhs \nonterm{equalityexpression} \lstinline@!=@\nonterm{relationalexpression}1713 \rhs \nonterm{equalityexpression} ©==© \nonterm{relationalexpression} 1714 \rhs \nonterm{equalityexpression} ©!=© \nonterm{relationalexpression} 1736 1715 \end{syntax} 1737 1716 … … 1792 1771 ?==?( forall( ftype FT2) FT2*, forall( ftype FT3) FT3 * ), ?!=?( forall( ftype FT2) FT2*, forall( ftype FT3) FT3 * ); 1793 1772 \end{lstlisting} 1794 For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@there exist1773 For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist 1795 1774 % Don't use predefined: keep this out of prelude.cf. 1796 1775 \begin{lstlisting} … … 1800 1779 1801 1780 \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.1781 The 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. 1803 1782 In the last case, a special constraint rule for null pointer constant operands has been replaced by a consequence of the \CFA type system. 1804 1783 \end{rationale} … … 1821 1800 \lhs{ANDexpression} 1822 1801 \rhs \nonterm{equalityexpression} 1823 \rhs \nonterm{ANDexpression} \lstinline@&@\nonterm{equalityexpression}1802 \rhs \nonterm{ANDexpression} ©&© \nonterm{equalityexpression} 1824 1803 \end{syntax} 1825 1804 … … 1838 1817 long long unsigned int ?&?( long long unsigned int, long long unsigned int ); 1839 1818 \end{lstlisting} 1840 For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@there exist1819 For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist 1841 1820 % Don't use predefined: keep this out of prelude.cf. 1842 1821 \begin{lstlisting} … … 1853 1832 \lhs{exclusiveORexpression} 1854 1833 \rhs \nonterm{ANDexpression} 1855 \rhs \nonterm{exclusiveORexpression} \lstinline@^@\nonterm{ANDexpression}1834 \rhs \nonterm{exclusiveORexpression} ©^© \nonterm{ANDexpression} 1856 1835 \end{syntax} 1857 1836 … … 1870 1849 long long unsigned int ?^?( long long unsigned int, long long unsigned int ); 1871 1850 \end{lstlisting} 1872 For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@there exist1851 For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist 1873 1852 % Don't use predefined: keep this out of prelude.cf. 1874 1853 \begin{lstlisting} … … 1885 1864 \lhs{inclusiveORexpression} 1886 1865 \rhs \nonterm{exclusiveORexpression} 1887 \rhs \nonterm{inclusiveORexpression} \lstinline@@\nonterm{exclusiveORexpression}1866 \rhs \nonterm{inclusiveORexpression} ©© \nonterm{exclusiveORexpression} 1888 1867 \end{syntax} 1889 1868 … … 1902 1881 long long unsigned int ??( long long unsigned int, long long unsigned int ); 1903 1882 \end{lstlisting} 1904 For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@there exist1883 For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist 1905 1884 % Don't use predefined: keep this out of prelude.cf. 1906 1885 \begin{lstlisting} … … 1917 1896 \lhs{logicalANDexpression} 1918 1897 \rhs \nonterm{inclusiveORexpression} 1919 \rhs \nonterm{logicalANDexpression} \lstinline@&&@\nonterm{inclusiveORexpression}1898 \rhs \nonterm{logicalANDexpression} ©&&© \nonterm{inclusiveORexpression} 1920 1899 \end{syntax} 1921 1900 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 builtin 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 nonzero. 1901 \semantics The operands of the expression ``©a && b©'' are treated as ``©(int)((a)!=0)©'' and ``©(int)((b)!=0)©'', which shall both be unambiguous. 1902 The expression has only one interpretation, which is of type ©int©. 1903 \begin{rationale} 1904 When the operands of a logical expression are values of builtin types, and ``©!=©'' has not been redefined for those types, the compiler can optimize away the function calls. 1905 1906 A common C idiom omits comparisons to ©0© in the controlling expressions of loops and ©if© statements. 1907 For instance, the loop below iterates as long as ©rp© points at a ©Rational© value that is nonzero. 1931 1908 1932 1909 \begin{lstlisting} … … 1937 1914 while ( rp && *rp ) { ... } 1938 1915 \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 programmerdefined \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.1916 The logical expression calls the ©Rational© inequality operator, passing it ©*rp© and the ©Rational 0©, and getting a 1 or 0 as a result. 1917 In contrast, {\CC} would apply a programmerdefined ©Rational©to©int© conversion to ©*rp© in the equivalent situation. 1918 The 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. 1942 1919 \end{rationale} 1943 1920 … … 1948 1925 \lhs{logicalORexpression} 1949 1926 \rhs \nonterm{logicalANDexpression} 1950 \rhs \nonterm{logicalORexpression} \lstinline@@\nonterm{logicalANDexpression}1927 \rhs \nonterm{logicalORexpression} ©© \nonterm{logicalANDexpression} 1951 1928 \end{syntax} 1952 1929 1953 1930 \semantics 1954 1931 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@.1932 The operands of the expression ``©a  b©'' are treated as ``©(int)((a)!=0)©'' and ``©(int)((b))!=0)©'', which shall both be unambiguous. 1933 The expression has only one interpretation, which is of type ©int©. 1957 1934 1958 1935 … … 1962 1939 \lhs{conditionalexpression} 1963 1940 \rhs \nonterm{logicalORexpression} 1964 \rhs \nonterm{logicalORexpression} \lstinline@?@\nonterm{expression}1965 \lstinline@:@\nonterm{conditionalexpression}1941 \rhs \nonterm{logicalORexpression} ©?© \nonterm{expression} 1942 ©:© \nonterm{conditionalexpression} 1966 1943 \end{syntax} 1967 1944 1968 1945 \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 to1946 In 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 1970 1947 \begin{lstlisting} 1971 1948 ( int)(( a)!=0) ? ( void)( b) : ( void)( c) 1972 1949 \end{lstlisting} 1973 1950 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 as1951 If 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 1975 1952 \begin{lstlisting} 1976 1953 forall( otype T ) T cond( int, T, T ); … … 2024 2001 rand() ? i : l; 2025 2002 \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@. 2003 The best interpretation infers the expression's type to be ©long© and applies the safe ©int©to©long© conversion to ©i©. 2028 2004 2029 2005 \begin{lstlisting} … … 2032 2008 rand() ? cip : vip; 2033 2009 \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.2010 The expression has type ©const volatile int *©, with safe conversions applied to the second and third operands to add ©volatile© and ©const© qualifiers, respectively. 2035 2011 2036 2012 \begin{lstlisting} 2037 2013 rand() ? cip : 0; 2038 2014 \end{lstlisting} 2039 The expression has type \lstinline@const int *@, with a specialization conversion applied to 2040 \lstinline@0@. 2015 The expression has type ©const int *©, with a specialization conversion applied to ©0©. 2041 2016 2042 2017 … … 2049 2024 \nonterm{assignmentexpression} 2050 2025 \lhs{assignmentoperator} one of 2051 \rhs \lstinline@=@\ \ \lstinline@*=@\ \ \lstinline@/=@\ \ \lstinline@%=@\ \ \lstinline@+=@\ \ \lstinline@=@\ \2052 \lstinline@<<=@\ \ \lstinline@>>=@\ \ \lstinline@&=@\ \ \lstinline@^=@\ \ \lstinline@=@2026 \rhs ©=©\ \ ©*=©\ \ ©/=©\ \ ©%=©\ \ ©+=©\ \ ©=©\ \ 2027 ©<<=©\ \ ©>>=©\ \ ©&=©\ \ ©^=©\ \ ©=© 2053 2028 \end{syntax} 2054 2029 … … 2064 2039 \semantics 2065 2040 Each interpretation of the left operand of an assignment expression is considered separately. 2066 For each interpretation that is a bitfield or is declared with the \lstinline@register@storage class specifier, the expression has one valid interpretation, with the type of the left operand.2041 For each interpretation that is a bitfield or is declared with the ©register© storage class specifier, the expression has one valid interpretation, with the type of the left operand. 2067 2042 The right operand is cast to that type, and the assignment expression is ambiguous if either operand is. 2068 2043 For the remaining interpretations, the expression is rewritten, and the interpretations of the assignment expression are the interpretations of the corresponding function call. … … 2297 2272 \end{lstlisting} 2298 2273 \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 exist2274 The 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 2277 For every complete structure or union type ©S© there exist 2303 2278 % Don't use predefined: keep this out of prelude.cf. 2304 2279 \begin{lstlisting} … … 2306 2281 \end{lstlisting} 2307 2282 2308 For every extended integer type \lstinline@X@there exist2283 For every extended integer type ©X© there exist 2309 2284 % Don't use predefined: keep this out of prelude.cf. 2310 2285 \begin{lstlisting} … … 2312 2287 \end{lstlisting} 2313 2288 2314 For every complete enumerated type \lstinline@E@there exist2289 For every complete enumerated type ©E© there exist 2315 2290 % Don't use predefined: keep this out of prelude.cf. 2316 2291 \begin{lstlisting} … … 2318 2293 \end{lstlisting} 2319 2294 \begin{rationale} 2320 The righthand argument is \lstinline@int@ because enumeration constants have type \lstinline@int@.2295 The righthand argument is ©int© because enumeration constants have type ©int©. 2321 2296 \end{rationale} 2322 2297 … … 2579 2554 \end{lstlisting} 2580 2555 2581 For every extended integer type \lstinline@X@there exist2556 For every extended integer type ©X© there exist 2582 2557 % Don't use predefined: keep this out of prelude.cf. 2583 2558 \begin{lstlisting} … … 2594 2569 \end{lstlisting} 2595 2570 2596 For every complete enumerated type \lstinline@E@there exist2571 For every complete enumerated type ©E© there exist 2597 2572 % Don't use predefined: keep this out of prelude.cf. 2598 2573 \begin{lstlisting} … … 2615 2590 \lhs{expression} 2616 2591 \rhs \nonterm{assignmentexpression} 2617 \rhs \nonterm{expression} \lstinline@,@\nonterm{assignmentexpression}2592 \rhs \nonterm{expression} ©,© \nonterm{assignmentexpression} 2618 2593 \end{syntax} 2619 2594 2620 2595 \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}. 2596 In the comma expression ``©a, b©'', the first operand is interpreted as ``©( void )(a)©'', which shall be unambiguous\index{ambiguous interpretation}. 2623 2597 The interpretations of the expression are the interpretations of the second operand. 2624 2598 … … 2655 2629 { ... } 2656 2630 \end{lstlisting} 2657 Without the rule, \lstinline@Complex@would be a type in the first case, and a parameter name in the second.2631 Without the rule, ©Complex© would be a type in the first case, and a parameter name in the second. 2658 2632 \end{rationale} 2659 2633 … … 2712 2686 \begin{syntax} 2713 2687 \lhs{forallspecifier} 2714 \rhs \lstinline@forall@ \lstinline@(@ \nonterm{typeparameterlist} \lstinline@)@2688 \rhs ©forall© ©(© \nonterm{typeparameterlist} ©)© 2715 2689 \end{syntax} 2716 2690 … … 2724 2698 } mkPair( T, T ); // illegal 2725 2699 \end{lstlisting} 2726 If an instance of \lstinline@struct Pair@was declared later in the current scope, what would the members' type be?2700 If an instance of ©struct Pair© was declared later in the current scope, what would the members' type be? 2727 2701 \end{rationale} 2728 2702 \end{comment} … … 2731 2705 The \nonterm{typeparameterlist}s and assertions of the \nonterm{forallspecifier}s declare type identifiers, function and object identifiers with \Index{no linkage}. 2732 2706 2733 If, in the declaration ``\lstinline@T D@'', \lstinline@T@ contains \nonterm{forallspecifier}s and 2734 \lstinline@D@ has the form 2707 If, in the declaration ``©T D©'', ©T© contains \nonterm{forallspecifier}s and ©D© has the form 2735 2708 \begin{lstlisting} 2736 2709 D( §\normalsize\nonterm{parametertypelist}§ ) 2737 \end{lstlisting} then a type identifier declared by one of the \nonterm{forallspecifier}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 following2710 \end{lstlisting} then a type identifier declared by one of the \nonterm{forallspecifier}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 2738 2711 \nonterm{typeparameterlist} or it and an inferred parameter are used as arguments of a 2739 2712 \Index{specification} in one of the \nonterm{forallspecifier}s. … … 2748 2721 forall( otype T ) T * alloc( void );§\use{alloc}§ int *p = alloc(); 2749 2722 \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@: 2723 Here ©alloc()© would receive ©int© as an inferred argument, and return an ©int *©. 2724 In 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 2726 With the current restriction, ©alloc()© must be given an argument that determines ©T©: 2756 2727 \begin{lstlisting} 2757 2728 forall( otype T ) T * alloc( T initial_value );§\use{alloc}§ … … 2780 2751 forall( otype T ) T fT( T ); 2781 2752 \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©. 2784 2754 \begin{lstlisting} 2785 2755 int (*pfi )( int ) = fi; 2786 2756 forall( otype T ) T (*pfT )( T ) = fT; 2787 2757 \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. 2789 2759 \begin{lstlisting} 2790 2760 int (*fvpfi( void ))( int ) { … … 2795 2765 } 2796 2766 \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. 2798 2768 \begin{lstlisting} 2799 2769 forall( otype T ) int ( *fTpfi( T ) )( int ); … … 2801 2771 forall( otype T, otype U ) U ( *fTpfU( T ) )( U ); 2802 2772 \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. 2774 It 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()©. 2776 For 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 *©. 2810 2778 \begin{lstlisting} 2811 2779 forall( otype T, otype U, otype V ) U * f( T *, U, V * const ); 2812 2780 forall( otype U, otype V, otype W ) U * g( V *, U, W * const ); 2813 2781 \end{lstlisting} 2814 The functions \lstinline@f()@ and \lstinline@g()@have compatible types.2782 The functions ©f()© and ©g()© have compatible types. 2815 2783 Let \(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@.2784 then \(f_1\) = ©T©, \(f_2\) = ©U©, \(f_3\) = ©V©, \(g_1\) 2785 = ©V©, \(g_2\) = ©U©, and \(g_3\) = ©W©. 2818 2786 Replacing every \(f_i\) by \(g_i\) in \(f\) gives 2819 2787 \begin{lstlisting} … … 2821 2789 \end{lstlisting} which has a return type and parameter list that is compatible with \(g\). 2822 2790 \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.2791 The 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. 2824 2792 2825 2793 Even without parameterized types, I might try to allow … … 2847 2815 \subsection{Type qualifiers} 2848 2816 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}. 2850 2818 \begin{syntax} 2851 2819 \oldlhs{typequalifier} 2852 \rhs \lstinline@lvalue@2820 \rhs ©lvalue© 2853 2821 \end{syntax} 2854 2822 … … 2858 2826 \semantics 2859 2827 An object's type may be a restrictqualified 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. 2861 2829 2862 2830 \begin{rationale} … … 2864 2832 \end{rationale} 2865 2833 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. 2835 Let ©T© be an unqualified version of a type; 2836 then 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} 2839 The ©const© and ©volatile© qualifiers can only be sensibly used to qualify the return type of a function if the ©lvalue© qualifier is also used. 2873 2840 \end{rationale} 2874 2841 … … 2877 2844 2878 2845 \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. 2880 2847 Reference types have four uses in {\CC}. 2881 2848 \begin{itemize} … … 2884 2851 2885 2852 \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.2853 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 ©with© statement. 2887 2854 The following {\CC} code gives an example. 2888 2855 \begin{lstlisting} … … 2897 2864 A reference parameter can be used to allow a function to modify an argument without forcing the caller to pass the address of the argument. 2898 2865 This is most useful for userdefined assignment operators. 2899 In {\CC}, plain assignment is done by a function called `` \lstinline@operator=@'', and the two expressions2866 In {\CC}, plain assignment is done by a function called ``©operator=©'', and the two expressions 2900 2867 \begin{lstlisting} 2901 2868 a = b; 2902 2869 operator=( a, b ); 2903 2870 \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 userdefined 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@&@''. 2871 If ©a© and ©b© are of type ©T©, then the first parameter of ©operator=© must have type ``©T&©''. 2872 It 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 2874 In the case of userdefined 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 )©''. 2875 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 ``©&©''. 2912 2876 2913 2877 \item 2914 2878 References to \Index{constqualified} 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@is2916 \lstinline@Thing@, the type of \lstinline@fiddle@could be either of2879 {\CC} function call ``©fiddle( a_thing )©'', where the type of ©a_thing© is 2880 ©Thing©, the type of ©fiddle© could be either of 2917 2881 \begin{lstlisting} 2918 2882 void fiddle( Thing ); 2919 2883 void fiddle( const Thing & ); 2920 2884 \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.2885 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 ©fiddle© the parameter is subject to the usual problems caused by aliases. 2886 The reference form might be chosen for efficiency's sake if ©Thing©s are too large or their constructors or destructors are too expensive. 2923 2887 An implementation may switch between them without causing trouble for wellbehaved clients. 2924 2888 This leaves the implementor to define ``too large'' and ``too expensive''. … … 2928 2892 void fiddle( const volatile Thing ); 2929 2893 \end{lstlisting} with callbyreference. 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''.2894 Since 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''. 2931 2895 \end{itemize} 2932 2896 … … 2948 2912 \begin{syntax} 2949 2913 \lhs{specdefinition} 2950 \rhs \lstinline@spec@\nonterm{identifier}2951 \lstinline@(@ \nonterm{typeparameterlist} \lstinline@)@2952 \lstinline@{@ \nonterm{specdeclarationlist}\opt \lstinline@}@2914 \rhs ©spec© \nonterm{identifier} 2915 ©(© \nonterm{typeparameterlist} ©)© 2916 ©{© \nonterm{specdeclarationlist}\opt ©}© 2953 2917 \lhs{specdeclarationlist} 2954 \rhs \nonterm{specdeclaration} \lstinline@;@2955 \rhs \nonterm{specdeclarationlist} \nonterm{specdeclaration} \lstinline@;@2918 \rhs \nonterm{specdeclaration} ©;© 2919 \rhs \nonterm{specdeclarationlist} \nonterm{specdeclaration} ©;© 2956 2920 \lhs{specdeclaration} 2957 2921 \rhs \nonterm{specifierqualifierlist} \nonterm{declaratorlist} 2958 2922 \lhs{declaratorlist} 2959 2923 \rhs \nonterm{declarator} 2960 \rhs \nonterm{declaratorlist} \lstinline@,@\nonterm{declarator}2924 \rhs \nonterm{declaratorlist} ©,© \nonterm{declarator} 2961 2925 \end{syntax} 2962 2926 \begin{rationale} … … 2980 2944 \rhs \nonterm{assertionlist} \nonterm{assertion} 2981 2945 \lhs{assertion} 2982 \rhs \lstinline@@ \nonterm{identifier} \lstinline@(@ \nonterm{typenamelist} \lstinline@)@2983 \rhs \lstinline@@\nonterm{specdeclaration}2946 \rhs ©© \nonterm{identifier} ©(© \nonterm{typenamelist} ©)© 2947 \rhs ©© \nonterm{specdeclaration} 2984 2948 \lhs{typenamelist} 2985 2949 \rhs \nonterm{typename} 2986 \rhs \nonterm{typenamelist} \lstinline@,@\nonterm{typename}2950 \rhs \nonterm{typenamelist} ©,© \nonterm{typename} 2987 2951 \end{syntax} 2988 2952 … … 2991 2955 The \nonterm{typenamelist} shall contain one \nonterm{typename} argument for each \nonterm{typeparameter} in that specification's \nonterm{specparameterlist}. 2992 2956 If the 2993 \nonterm{typeparameter} uses typeclass \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{typeparameter} uses typeclass ©type©\use{type}, the argument shall be the type name of an \Index{object type}; 2958 if it uses ©dtype©, the argument shall be the type name of an object type or an \Index{incomplete type}; 2959 and if it uses ©ftype©, the argument shall be the type name of a \Index{function type}. 2996 2960 2997 2961 \semantics … … 3023 2987 trait sum_list( otype List, otype Element  summable( Element )  list_of( List, Element ) ) {}; 3024 2988 \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 parameters2989 ©sum_list© contains seven declarations, which describe a list whose elements can be added up. 2990 The assertion ``©sum_list( i_list, int )©''\use{sum_list} produces the assertion parameters 3027 2991 \begin{lstlisting} 3028 2992 int ?+=?( int *, int ); … … 3041 3005 \lhs{typeparameterlist} 3042 3006 \rhs \nonterm{typeparameter} 3043 \rhs \nonterm{typeparameterlist} \lstinline@,@\nonterm{typeparameter}3007 \rhs \nonterm{typeparameterlist} ©,© \nonterm{typeparameter} 3044 3008 \lhs{typeparameter} 3045 3009 \rhs \nonterm{typeclass} \nonterm{identifier} \nonterm{assertionlist}\opt 3046 3010 \lhs{typeclass} 3047 \rhs \lstinline@type@3048 \rhs \lstinline@dtype@3049 \rhs \lstinline@ftype@3011 \rhs ©type© 3012 \rhs ©dtype© 3013 \rhs ©ftype© 3050 3014 \lhs{typedeclaration} 3051 \rhs \nonterm{storageclassspecifier}\opt \lstinline@type@\nonterm{typedeclaratorlist} \verb;3015 \rhs \nonterm{storageclassspecifier}\opt ©type© \nonterm{typedeclaratorlist} \verb; 3052 3016 \lhs{typedeclaratorlist} 3053 3017 \rhs \nonterm{typedeclarator} 3054 \rhs \nonterm{typedeclaratorlist} \lstinline@,@\nonterm{typedeclarator}3018 \rhs \nonterm{typedeclaratorlist} ©,© \nonterm{typedeclarator} 3055 3019 \lhs{typedeclarator} 3056 \rhs \nonterm{identifier} \nonterm{assertionlist}\opt \lstinline@=@\nonterm{typename}3020 \rhs \nonterm{identifier} \nonterm{assertionlist}\opt ©=© \nonterm{typename} 3057 3021 \rhs \nonterm{identifier} \nonterm{assertionlist}\opt 3058 3022 \end{syntax} … … 3065 3029 3066 3030 An identifier declared by a \nonterm{typeparameter} has \Index{no linkage}. 3067 Identifiers declared with typeclass \lstinline@type@\use{type} are \Index{object type}s; 3068 those declared with typeclass 3069 \lstinline@dtype@\use{dtype} are \Index{incomplete type}s; 3070 and those declared with typeclass 3071 \lstinline@ftype@\use{ftype} are \Index{function type}s. 3031 Identifiers declared with typeclass ©type©\use{type} are \Index{object type}s; 3032 those declared with typeclass ©dtype©\use{dtype} are \Index{incomplete type}s; 3033 and those declared with typeclass ©ftype©\use{ftype} are \Index{function type}s. 3072 3034 The identifier has \Index{block scope} that terminates at the end of the \nonterm{specdeclarationlist} or polymorphic function that contains the \nonterm{typeparameter}. 3073 3035 … … 3077 3039 Within 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. 3078 3040 3079 A type declaration without an \Index{initializer} and without a \Index{storageclass specifier} or with storageclass specifier \lstinline@static@\use{static} defines an \Index{incomplete type}.3041 A type declaration without an \Index{initializer} and without a \Index{storageclass specifier} or with storageclass specifier ©static©\use{static} defines an \Index{incomplete type}. 3080 3042 If a 3081 3043 \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). … … 3096 3058 \end{rationale} 3097 3059 3098 A type declaration without an initializer and with \Index{storageclass specifier} 3099 \lstinline@extern@\use{extern} is an \define{opaque type declaration}. 3060 A type declaration without an initializer and with \Index{storageclass specifier} ©extern©\use{extern} is an \define{opaque type declaration}. 3100 3061 Opaque types are 3101 3062 \Index{object type}s. … … 3112 3073 \end{rationale} 3113 3074 3114 An \Index{incomplete type} which is not a qualified version\index{qualified type} of a type is a value of \Index{typeclass} \lstinline@dtype@.3115 An object type\index{object types} which is not a qualified version of a type is a value of typeclasses \lstinline@type@ and \lstinline@dtype@.3075 An \Index{incomplete type} which is not a qualified version\index{qualified type} of a type is a value of \Index{typeclass} ©dtype©. 3076 An object type\index{object types} which is not a qualified version of a type is a value of typeclasses ©type© and ©dtype©. 3116 3077 A 3117 \Index{function type} is a value of typeclass \lstinline@ftype@.3078 \Index{function type} is a value of typeclass ©ftype©. 3118 3079 \begin{rationale} 3119 3080 Syntactically, a type value is a \nonterm{typename}, which is a declaration for an object which omits the identifier being declared. … … 3124 3085 3125 3086 Type 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. 3087 Consider 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. 3128 3088 \begin{lstlisting} 3129 3089 char *strchr( const char *s, int c ) {§\impl{strchr}§ … … 3134 3094 } 3135 3095 \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 nonconstant string. 3137 Hence the body must perform a cast, and ( even worse) 3138 \lstinline@strchr()@ provides a typesafe 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. 3096 The 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 nonconstant string. 3097 Hence the body must perform a cast, and ( even worse) ©strchr()© provides a typesafe way to attempt to modify constant strings. 3098 What is needed is some way to say that ©s©'s type might contain qualifiers, and the result type has exactly the same qualifiers. 3140 3099 Polymorphic 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.3100 Instead, overloading can be used to define ©strchr()© for each combination of qualifiers. 3142 3101 \end{rationale} 3143 3102 … … 3163 3122 }; 3164 3123 \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@. 3124 Without 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©. 3167 3125 3168 3126 A 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. … … 3181 3139 \nonterm{structdeclaration}, type declarations can not be structure members. 3182 3140 The form of 3183 \nonterm{typedeclaration} forbids arrays of, pointers to, and functions returning \lstinline@type@.3141 \nonterm{typedeclaration} forbids arrays of, pointers to, and functions returning ©type©. 3184 3142 Hence the syntax of \nonterm{typespecifier} does not have to be extended to allow typevalued expressions. 3185 3143 It also sidesteps the problem of typevalued expressions producing different values in different declarations. … … 3198 3156 §\ldots§ int * ip = new( int ); 3199 3157 \end{lstlisting} 3200 This looks sensible, but \CFA's declarationbeforeuse 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@;3158 This looks sensible, but \CFA's declarationbeforeuse 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©; 3201 3159 it could be undefined, or a type name, or a function or variable name. 3202 3160 Nothing good can result from such a situation. … … 3215 3173 f2( v2 ); 3216 3174 \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]©. 3218 3176 3219 3177 A translation unit containing the declarations … … 3221 3179 extern type Complex;§\use{Complex}§ // opaque type declaration 3222 3180 extern 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©. 3182 Some other translation unit must implement ©Complex© and ©abs©. 3225 3183 That unit might contain the declarations 3226 3184 \begin{lstlisting} … … 3231 3189 } 3232 3190 \end{lstlisting} 3233 Note that \lstinline@c@ is implicitly converted to a \lstinline@struct@so that its components can be retrieved.3191 Note that ©c© is implicitly converted to a ©struct© so that its components can be retrieved. 3234 3192 3235 3193 \begin{lstlisting} … … 3239 3197 } 3240 3198 \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. 3242 3200 3243 3201 \begin{rationale} 3244 3202 Within 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.3203 In the ©Time_of_day© example, the difference is important. 3246 3204 Different languages have treated the distinction between the abstraction and the implementation in different ways. 3247 3205 \begin{itemize} 3248 3206 \item 3249 3207 Inside 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.3208 Two primitives called ©up© and ©down© can be used to convert between the views. 3251 3209 \item 3252 3210 The Simula class \cite{SIMULA87} is essentially a record type. 3253 3211 Since 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. 3254 3212 In {\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. 3256 3214 A ``scope resolution'' operator can be used inside the class to specify whether the abstract or implementation version of the operation should be used. 3257 3215 \item … … 3266 3224 In this case, explicit conversions between the derived type and the old type can be used. 3267 3225 \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©. 3269 3227 \end{rationale} 3270 3228 … … 3272 3230 \subsubsection{Default functions and objects} 3273 3231 3274 A declaration\index{type declaration} of a type identifier \lstinline@T@ with typeclass 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@. 3232 A declaration\index{type declaration} of a type identifier ©T© with typeclass ©type© implicitly declares a \define{default assignment} function ©T ?=?( T *, T )©\use{?=?}, with the same \Index{scope} and \Index{linkage} as the identifier ©T©. 3277 3233 \begin{rationale} 3278 3234 Assignment 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). 3279 3235 Without 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. 3236 If a type parameter should not have an assignment operation, ©dtype© should be used. 3282 3237 If a type should not have assignment defined, the user can define an assignment function that causes a runtime error, or provide an external declaration but no definition and thus cause a linktime error. 3283 3238 \end{rationale} 3284 3239 3285 A definition\index{type definition} of a type identifier \lstinline@T@ with \Index{implementation type} \lstinline@I@ and typeclass \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 and3240 A definition\index{type definition} of a type identifier ©T© with \Index{implementation type} ©I© and typeclass ©type© implicitly defines a default assignment function. 3241 A definition\index{type definition} of a type identifier ©T© with implementation type ©I© and an assertion list implicitly defines \define{default function}s and 3287 3242 \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@.3243 The default objects and functions have the same \Index{scope} and \Index{linkage} as the identifier ©T©. 3289 3244 Their values are determined as follows: 3290 3245 \begin{itemize} 3291 3246 \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.3247 If 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. 3248 Otherwise the scope of the declaration of ©T© must contain a definition of the default object. 3294 3249 3295 3250 \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.3251 If 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 3253 Otherwise, 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 3255 Otherwise the scope of the declaration of ©T© must contain a definition of the default function. 3301 3256 \end{itemize} 3302 3257 \begin{rationale} … … 3304 3259 \end{rationale} 3305 3260 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.3261 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 ©T© replaces the default function or object. 3307 3262 3308 3263 \examples … … 3314 3269 Pair b = { 1, 1 }; 3315 3270 \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. 3271 The definition of ©Pair© implicitly defines two objects ©a© and ©b©. 3272 ©Pair a© inherits its value from the ©struct impl a©. 3273 The definition of ©Pair b© is compulsory because there is no ©struct impl b© to construct a value from. 3320 3274 \begin{lstlisting} 3321 3275 trait ss( otype T ) { … … 3330 3284 Doodad clone( Doodad ) { ... } 3331 3285 \end{lstlisting} 3332 The definition of \lstinline@Doodad@implicitly defines three functions:3286 The definition of ©Doodad© implicitly defines three functions: 3333 3287 \begin{lstlisting} 3334 3288 Doodad ?=?( Doodad *, Doodad ); … … 3336 3290 void munge( Doodad * ); 3337 3291 \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. 3292 The 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. 3294 Hence the definition of ``©Doodad clone( Doodad )©'' is necessary. 3344 3295 3345 3296 Default functions and objects are subject to the normal scope rules. … … 3381 3332 \begin{syntax} 3382 3333 \oldlhs{labeledstatement} 3383 \rhs \lstinline@case@\nonterm{casevaluelist} : \nonterm{statement}3334 \rhs ©case© \nonterm{casevaluelist} : \nonterm{statement} 3384 3335 \lhs{casevaluelist} 3385 3336 \rhs \nonterm{casevalue} 3386 \rhs \nonterm{casevaluelist} \lstinline@,@\nonterm{casevalue}3337 \rhs \nonterm{casevaluelist} ©,© \nonterm{casevalue} 3387 3338 \lhs{casevalue} 3388 3339 \rhs \nonterm{constantexpression} 3389 3340 \rhs \nonterm{subrange} 3390 3341 \lhs{subrange} 3391 \rhs \nonterm{constantexpression} \lstinline@~@\nonterm{constantexpression}3342 \rhs \nonterm{constantexpression} ©~© \nonterm{constantexpression} 3392 3343 \end{syntax} 3393 3344 … … 3402 3353 case 1~4, 9~14, 27~32: 3403 3354 \end{lstlisting} 3404 The \lstinline@case@ and \lstinline@default@ clauses are restricted within the \lstinline@switch@ and \lstinline@choose@statements, precluding Duff's device.3355 The ©case© and ©default© clauses are restricted within the ©switch© and ©choose© statements, precluding Duff's device. 3405 3356 3406 3357 3407 3358 \subsection{Expression and null statements} 3408 3359 3409 The expression in an expression statement is treated as being cast to \lstinline@void@.3360 The expression in an expression statement is treated as being cast to ©void©. 3410 3361 3411 3362 … … 3414 3365 \begin{syntax} 3415 3366 \oldlhs{selectionstatement} 3416 \rhs \lstinline@choose@ \lstinline@(@ \nonterm{expression} \lstinline@)@\nonterm{statement}3367 \rhs ©choose© ©(© \nonterm{expression} ©)© \nonterm{statement} 3417 3368 \end{syntax} 3418 3369 3419 The controlling expression \lstinline@E@ in the \lstinline@switch@ and \lstinline@choose@statement:3370 The controlling expression ©E© in the ©switch© and ©choose© statement: 3420 3371 \begin{lstlisting} 3421 3372 switch ( E ) ... … … 3423 3374 \end{lstlisting} may have more than one interpretation, but it shall have only one interpretation with an integral type. 3424 3375 An \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.3376 The constant expressions in ©case© statements with the switch are converted to the promoted type. 3426 3377 3427 3378 … … 3429 3380 \subsubsection[The choose statement]{The \lstinline@choose@ statement} 3430 3381 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.3382 The ©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. 3383 The ©fallthru© statement is used to fall through to the next ©case© or ©default© labeled statement. 3433 3384 The following have identical meaning: 3434 3385 \begin{flushleft} … … 3455 3406 \end{tabular} 3456 3407 \end{flushleft} 3457 The \lstinline@choose@ statement addresses the problem of accidental fallthrough associated with the \lstinline@switch@statement.3408 The ©choose© statement addresses the problem of accidental fallthrough associated with the ©switch© statement. 3458 3409 3459 3410 3460 3411 \subsection{Iteration statements} 3461 3412 3462 The controlling expression \lstinline@E@in the loops3413 The controlling expression ©E© in the loops 3463 3414 \begin{lstlisting} 3464 3415 if ( E ) ... 3465 3416 while ( E ) ... 3466 3417 do ... while ( E ); 3467 \end{lstlisting} is treated as ``\lstinline@( int )((E)!=0)@''. 3418 \end{lstlisting} 3419 is treated as ``©( int )((E)!=0)©''. 3468 3420 3469 3421 The statement … … 3480 3432 \begin{syntax} 3481 3433 \oldlhs{jumpstatement} 3482 \rhs \lstinline@continue@\nonterm{identifier}\opt3483 \rhs \lstinline@break@\nonterm{identifier}\opt3434 \rhs ©continue© \nonterm{identifier}\opt 3435 \rhs ©break© \nonterm{identifier}\opt 3484 3436 \rhs \ldots 3485 \rhs \lstinline@throw@\nonterm{assignmentexpression}\opt3486 \rhs \lstinline@throwResume@\nonterm{assignmentexpression}\opt \nonterm{atexpression}\opt3487 \lhs{atexpression} \lstinline@_At@\nonterm{assignmentexpression}3437 \rhs ©throw© \nonterm{assignmentexpression}\opt 3438 \rhs ©throwResume© \nonterm{assignmentexpression}\opt \nonterm{atexpression}\opt 3439 \lhs{atexpression} ©_At© \nonterm{assignmentexpression} 3488 3440 \end{syntax} 3489 3441 3490 Labeled \lstinline@continue@ and \lstinline@break@ allow useful but restricted controlflow that reduces the need for the \lstinline@goto@statement for exiting multiple nested controlstructures.3442 Labeled ©continue© and ©break© allow useful but restricted controlflow that reduces the need for the ©goto© statement for exiting multiple nested controlstructures. 3491 3443 \begin{lstlisting} 3492 3444 L1: { // compound … … 3517 3469 \subsubsection[The continue statement]{The \lstinline@continue@ statement} 3518 3470 3519 The identifier in a \lstinline@continue@statement shall name a label located on an enclosing iteration statement.3471 The identifier in a ©continue© statement shall name a label located on an enclosing iteration statement. 3520 3472 3521 3473 3522 3474 \subsubsection[The break statement]{The \lstinline@break@ statement} 3523 3475 3524 The identifier in a \lstinline@break@statement shall name a label located on an enclosing compound, selection or iteration statement.3476 The identifier in a ©break© statement shall name a label located on an enclosing compound, selection or iteration statement. 3525 3477 3526 3478 3527 3479 \subsubsection[The return statement]{The \lstinline@return@ statement} 3528 3480 3529 An expression in a \lstinline@return@statement is treated as being cast to the result type of the function.3481 An expression in a ©return© statement is treated as being cast to the result type of the function. 3530 3482 3531 3483 … … 3542 3494 \begin{syntax} 3543 3495 \lhs{exceptionstatement} 3544 \rhs \lstinline@try@\nonterm{compoundstatement} \nonterm{handlerlist}3545 \rhs \lstinline@try@\nonterm{compoundstatement} \nonterm{finallyclause}3546 \rhs \lstinline@try@\nonterm{compoundstatement} \nonterm{handlerlist} \nonterm{finallyclause}3496 \rhs ©try© \nonterm{compoundstatement} \nonterm{handlerlist} 3497 \rhs ©try© \nonterm{compoundstatement} \nonterm{finallyclause} 3498 \rhs ©try© \nonterm{compoundstatement} \nonterm{handlerlist} \nonterm{finallyclause} 3547 3499 \lhs{handlerlist} 3548 3500 \rhs \nonterm{handlerclause} 3549 \rhs \lstinline@catch@ \lstinline@(@ \ldots \lstinline@)@\nonterm{compoundstatement}3550 \rhs \nonterm{handlerclause} \lstinline@catch@ \lstinline@(@ \ldots \lstinline@)@\nonterm{compoundstatement}3551 \rhs \lstinline@catchResume@ \lstinline@(@ \ldots \lstinline@)@\nonterm{compoundstatement}3552 \rhs \nonterm{handlerclause} \lstinline@catchResume@ \lstinline@(@ \ldots \lstinline@)@\nonterm{compoundstatement}3501 \rhs ©catch© ©(© \ldots ©)© \nonterm{compoundstatement} 3502 \rhs \nonterm{handlerclause} ©catch© ©(© \ldots ©)© \nonterm{compoundstatement} 3503 \rhs ©catchResume© ©(© \ldots ©)© \nonterm{compoundstatement} 3504 \rhs \nonterm{handlerclause} ©catchResume© ©(© \ldots ©)© \nonterm{compoundstatement} 3553 3505 \lhs{handlerclause} 3554 \rhs \lstinline@catch@ \lstinline@(@ \nonterm{exceptiondeclaration} \lstinline@)@\nonterm{compoundstatement}3555 \rhs \nonterm{handlerclause} \lstinline@catch@ \lstinline@(@ \nonterm{exceptiondeclaration} \lstinline@)@\nonterm{compoundstatement}3556 \rhs \lstinline@catchResume@ \lstinline@(@ \nonterm{exceptiondeclaration} \lstinline@)@\nonterm{compoundstatement}3557 \rhs \nonterm{handlerclause} \lstinline@catchResume@ \lstinline@(@ \nonterm{exceptiondeclaration} \lstinline@)@\nonterm{compoundstatement}3506 \rhs ©catch© ©(© \nonterm{exceptiondeclaration} ©)© \nonterm{compoundstatement} 3507 \rhs \nonterm{handlerclause} ©catch© ©(© \nonterm{exceptiondeclaration} ©)© \nonterm{compoundstatement} 3508 \rhs ©catchResume© ©(© \nonterm{exceptiondeclaration} ©)© \nonterm{compoundstatement} 3509 \rhs \nonterm{handlerclause} ©catchResume© ©(© \nonterm{exceptiondeclaration} ©)© \nonterm{compoundstatement} 3558 3510 \lhs{finallyclause} 3559 \rhs \lstinline@finally@\nonterm{compoundstatement}3511 \rhs ©finally© \nonterm{compoundstatement} 3560 3512 \lhs{exceptiondeclaration} 3561 3513 \rhs \nonterm{typespecifier} … … 3565 3517 \rhs \nonterm{newabstractdeclaratortuple} 3566 3518 \lhs{asynchronousstatement} 3567 \rhs \lstinline@enable@\nonterm{identifierlist} \nonterm{compoundstatement}3568 \rhs \lstinline@disable@\nonterm{identifierlist} \nonterm{compoundstatement}3519 \rhs ©enable© \nonterm{identifierlist} \nonterm{compoundstatement} 3520 \rhs ©disable© \nonterm{identifierlist} \nonterm{compoundstatement} 3569 3521 \end{syntax} 3570 3522 … … 3574 3526 \subsubsection[The try statement]{The \lstinline@try@ statement} 3575 3527 3576 The \lstinline@try@statement is a block with associated handlers, called a \Index{guarded block};3528 The ©try© statement is a block with associated handlers, called a \Index{guarded block}; 3577 3529 all 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.3530 A ©goto©, ©break©, ©return©, or ©continue© statement can be used to transfer control out of a try block or handler, but not into one. 3579 3531 3580 3532 3581 3533 \subsubsection[The enable/disable statements]{The \lstinline@enable@/\lstinline@disable@ statements} 3582 3534 3583 The \lstinline@enable@/\lstinline@disable@statements toggle delivery of \Index{asynchronous exception}s.3535 The ©enable©/©disable© statements toggle delivery of \Index{asynchronous exception}s. 3584 3536 3585 3537 … … 3591 3543 \subsection{Predefined macro names} 3592 3544 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. 3545 The implementation shall define the macro names ©__LINE__©, ©__FILE__©, ©__DATE__©, and ©__TIME__©, as in the {\c11} standard. 3546 It shall not define the macro name ©__STDC__©. 3547 3548 In addition, the implementation shall define the macro name ©__CFORALL__© to be the decimal constant 1. 3598 3549 3599 3550 … … 3612 3563 The pointer, integral, and floatingpoint types are all \define{scalar types}. 3613 3564 All of these types can be logically negated and compared. 3614 The assertion `` \lstinline@scalar( Complex )@'' should be read as ``type \lstinline@Complex@is scalar''.3565 The assertion ``©scalar( Complex )©'' should be read as ``type ©Complex© is scalar''. 3615 3566 \begin{lstlisting} 3616 3567 trait scalar( otype T ) {§\impl{scalar}§ … … 3630 3581 \end{lstlisting} 3631 3582 3632 The various flavors of \lstinline@char@ and \lstinline@int@and the enumerated types make up the3583 The various flavors of ©char© and ©int© and the enumerated types make up the 3633 3584 \define{integral types}. 3634 3585 \begin{lstlisting} … … 3664 3615 3665 3616 Modifiable arithmetic lvalues are both modifiable scalar lvalues and arithmetic. 3666 Note that this results in the ``inheritance'' of \lstinline@scalar@along both paths.3617 Note that this results in the ``inheritance'' of ©scalar© along both paths. 3667 3618 \begin{lstlisting} 3668 3619 trait m_l_arithmetic( otype T  m_l_scalar( T )  arithmetic( T ) ) {§\impl{m_l_arithmetic}§ … … 3679 3630 \subsection{Pointer and array types} 3680 3631 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. 3632 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 ``©a[i]©'' is equivalent to the dereferencing expression ``©(*( a+( i )))©''. 3633 Technically, 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. 3685 3634 Consequently, there is no need for a separate ``array type'' specification. 3686 3635 3687 3636 Pointer 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@. 3637 Like 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©. 3691 3638 \begin{lstlisting} 3692 3639 trait pointer( type P  scalar( P ) ) {§\impl{pointer}§§\use{scalar}§ … … 3703 3650 Specifications that define the dereference operator ( or subscript operator ) require two parameters, one for the pointer type and one for the pointedat ( or element ) type. 3704 3651 Different 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@''. 3652 The assertion ``©ptr_to( Safe_pointer, int )©'' should be read as ``©Safe_pointer© acts like a pointer to ©int©''. 3707 3653 \begin{lstlisting} 3708 3654 trait ptr_to( otype P  pointer( P ), otype T ) {§\impl{ptr_to}§§\use{pointer}§ … … 3724 3670 \end{lstlisting} 3725 3671 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 pointedat 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 pointedat type is passed in, so that assertions can connect these specifications to the 3728 ``\lstinline@ptr_to@'' specifications. 3672 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 pointedat type: a ``©T *©'' can be assigned to a ``©const T *©'', a ``©volatile T *©'', and a ``©const volatile T *©''. 3673 Again, the pointedat type is passed in, so that assertions can connect these specifications to the ``©ptr_to©'' specifications. 3729 3674 \begin{lstlisting} 3730 3675 trait 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}§ { … … 3755 3700 }; 3756 3701 \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. 3702 The assertion ``© m_l_ptr_like( Safe_ptr, const int * )©'' should be read as ``©Safe_ptr© is a pointer type like ©const int *©''. 3703 This 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. 3762 3704 3763 3705 … … 3765 3707 3766 3708 Different operators often have related meanings; 3767 for instance, in C, ``\lstinline@+@'', 3768 ``\lstinline@+=@'', and the two versions of ``\lstinline@++@'' perform variations of addition. 3709 for instance, in C, ``©+©'', ``©+=©'', and the two versions of ``©++©'' perform variations of addition. 3769 3710 Languages 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. 3770 3711 Completeness and consistency is left to the good taste and discretion of the programmer. … … 3779 3720 The different comparison operators have obvious relationships, but there is no obvious subset of the operations to use in the implementation of the others. 3780 3721 However, 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, nonobvious comparison operator: `` \lstinline@!@'', logical negation, returns 1 if its operand compares equal to 0, and 0 otherwise.3722 the library function ©strcmp© is an example. 3723 3724 C and \CFA have an extra, nonobvious comparison operator: ``©!©'', logical negation, returns 1 if its operand compares equal to 0, and 0 otherwise. 3784 3725 \begin{lstlisting} 3785 3726 trait comparable( otype T ) { … … 3829 3770 \end{lstlisting} 3830 3771 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@. 3772 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 ©int_base©, ©arith_base© and ©comparable©. 3833 3773 Note 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!3774 A truly minimal implementation of an arithmetic type might only provide ©0©, ©1©, and ©?=?©, which would be used by polymorphic ©?+=?©, ©?*=?©, and ©?/=?© functions. 3775 3776 Note also that ©short© is an integer type in C11 terms, but has no operations! 3837 3777 3838 3778 … … 3841 3781 3842 3782 Restrict 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.3783 This gets into ©noalias© territory. 3784 Qualifying anything (``©short restrict rs©'') means pointer parameters of ©?++©, etc, would need restrict qualifiers. 3845 3785 3846 3786 Enumerated types. … … 3852 3792 Color, enum Color ) really make sense? ?++ does, but it adds (int)1. 3853 3793 3854 Operators on {,signed,unsigned} char and other small types. \lstinline@?<?@harmless;3794 Operators on {,signed,unsigned} char and other small types. ©?<?© harmless; 3855 3795 ?*? questionable for chars. 3856 3796 Generic 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. 3797 Safe 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 3801 Don't use ©ptrdiff_t© by name in the predefineds. 3863 3802 3864 3803 Polymorphic objects.
Note: See TracChangeset
for help on using the changeset viewer.