Context Navigation

-                      rb08ab18
+                      rd63746f
 Specifically, an enumerated type restricts its values to a fixed set of named constants.
 While all types are restricted to a fixed set of values because of the underlying von Neumann architecture, and hence, to a corresponding set of constants, e.g., @3@, @3.5@, @3.5+2.1i@, @'c'@, @"abc"@, etc., these values are not named, other than the programming-language supplied constants.
 Fundamentally, all enumeration systems have an \newterm{enumeration} type with its associated \newterm{enumerator} constants.
 These components have three universal attributes, \newterm{position}, \newterm{label}, and \newterm{value}, as shown by this representative enumeration, where position and value can be different.
+While all types are restricted to a fixed set of values because of the underlying von Neumann architecture, and hence, to a corresponding set of constants, e.g., @3@, @3.5@, @3.5+2.1i@, @'c'@, @"abc"@, etc., these values are not named, other than the programming-language supplied constant names.
+Fundamentally, all enumeration systems have an \newterm{enumeration} type with an associated set of \newterm{enumerator} names.
+An enumeration has three universal attributes, \newterm{position}, \newterm{label}, and \newterm{value}, as shown by this representative enumeration, where position and value can be different.
 \begin{cquote}
 \small\sf\setlength{\tabcolsep}{3pt}
 …
 This feature allow enumerator lines to be interchanged without moving a comma.\footnote{
 A terminating comma appears in other C syntax, e.g., the initializer list.}
 Finally, C enumerators are \newterm{unscoped}, i.e., enumerators declared inside of an @enum@ are visible (projected) in the enclosing scope of the @enum@ type.
+Finally, C enumerators are \newterm{unscoped}, i.e., enumerators declared inside of an @enum@ are visible (projected) into the enclosing scope of the @enum@ type.
 In theory, a C enumeration \emph{variable} is an implementation-defined integral type large enough to hold all enumerated values.
 …
 In C, unscoping of enumerators presents a \newterm{naming problem} when multiple enumeration types appear in the same scope with duplicate enumerator names.
 There is no mechanism in C to resolve these naming conflicts other than renaming of one of the duplicates, which may not be possible.
+There is no mechanism in C to resolve these naming conflicts other than renaming of one of the duplicates, which may be impossible.
 The \CFA type-system allows extensive overloading, including enumerators.
 …
         C1 e1 = First;   C2 e2 = First;
         e1 = Second;   e2 = Second;
         e1 = p();   e2 = p();
         e1 = @C1.@First + @C1.@First;           $\C{// ambiguous without qualification (and dangerous)}$
+        e1 = p();   e2 = p();                           $\C{// correctly resolved function call}$
+        int i = @C1.@First + @C2.@First;        $\C{// ambiguous without qualification}$
+}
 \end{lstlisting}
 \CFA overloading allows programmers to use the most meaningful names with little fear of unresolvable clashes from included files, which can always be corrected.
+\CFA overloading allows programmers to use the most meaningful names without fear of unresolvable clashes from included files, which are correctable with qualification.
 …
 enum( char * ) Names @!@ { /* as above */ };
 \end{lstlisting}
 Now the enumerators must be qualified with the associated enumeration.
+Now the enumerators \emph{must} be qualified with the associated enumeration.
 \begin{lstlisting}
 Weekday weekday = @Weekday@.Monday;
 …
 names = @Names.@Jane;
 \end{lstlisting}
 It is possible to toggle back to unscoping using the \CFA @with@ clause/statement.
+It is possible to toggle back to unscoping using the \CFA @with@ clause/statement (see also \CC \lstinline[language=c++]{using enum} in Section~\ref{s:C++RelatedWork}).
 \begin{lstlisting}
 Weekday weekday;
 …
+}
 \end{lstlisting}
+As in section~\ref{s:EnumeratorNameResolution}, opening multiple unscoped enumerations can result in duplicate enumeration names, but \CFA type resolution and falling back to explicit qualification handles ambiguities.
+As in Section~\ref{s:EnumeratorNameResolution}, opening multiple unscoped enumerations can result in duplicate enumeration names, but \CFA type resolution and falling back to explicit qualification handles name resolution.
 \subsection{Enumerator Typing}
 …
 Figure~\ref{f:EumeratorTyping} shows a series of examples illustrating that all \CFA types can be use with an enumeration and each type's constants used to set the enumerator constants.
 Note, the synonyms @Liz@ and @Beth@ in the last declaration.
+Because enumerators are constants, the enumeration type is implicitly @const@, so all the enumerator types in Figure~\ref{f:EumeratorTyping} are rewritten with @const@.
+A typed enumeration has an implicit (safe) conversion to its base type.
+\begin{lstlisting}
+char currency = Dollar;
+string fred = Fred;                                             $\C{// implicit conversion from char * to \CFA string type}$
+Person student = Beth;
+\end{lstlisting}
 % \begin{lstlisting}[label=lst:color]
 …
 };
 \end{lstlisting}
+Note, the enumeration type can be a structure (see @Person@ in Figure~\ref{f:EumeratorTyping}), so it is possible to have the equivalent of multiple arrays of companion data using an array of structures.
 \subsection{Pure Enumerators}
 An empty type, @enum()@, implies the enumerators are pure symbols without values;
+An empty enumerator type, @enum()@, implies the enumerators are pure symbols without values but set properties;
 hence, there is no default conversion to @int@.
 …
 enum() Mode { O_RDONLY, O_WRONLY, O_CREAT, O_TRUNC, O_APPEND };
 @***@Mode iomode = O_RDONLY;
+bool b = iomode == O_RDONLY || iomode < O_APPEND;
 int i = iomode;                                                 $\C{\color{red}// disallowed}$
 \end{lstlisting}
 …
 If follows from enumerator typing that the enumerator type can be another enumerator.
 \begin{lstlisting}
+enum( @char@ ) Currency { Dollar = '$\textdollar$', Euro = '$\texteuro$', Pound = '$\textsterling$'  };
+enum( @Currency@ ) Europe { Euro = Currency.Euro, Pound = Currency.Pound }; // intersection
 enum( char ) Letter { A = 'A',  B = 'B', C = 'C', ..., Z = 'Z' };
 enum( @Letter@ ) Greek { Alph = A, Beta = B, ..., Zeta = Z }; // alphabet intersection
 \end{lstlisting}
 Enumeration @Greek@ may have more or less enumerators than @Letter@, but the enumerator values must be from @Letter@.
 Therefore, @Greek@ enumerators are a subset of type @Letter@ and are type compatible with enumeration @Letter@, but @Letter@ enumerators are not type compatible with enumeration @Greek@.
+enum( @Letter@ ) Greek { Alph = A, Beta = B, ..., Zeta = Z }; // intersection
+\end{lstlisting}
+Subset enumerations may have more or less enumerators than their typed enumeration, but the enumerator values must be from the typed enumeration.
+For example, @Greek@ enumerators are a subset of type @Letter@ and are type compatible with enumeration @Letter@, but @Letter@ enumerators are not type compatible with enumeration @Greek@.
 \begin{lstlisting}
 Letter letter = A;
 …
 \subsection{Enumeration Inheritance}
 \CFA Plan-9 inheritance may be used with enumerations.
+\CFA Plan-9 inheritance may be used with enumerations, where Plan-9 inheritance is containment inheritance with implicit unscoping (like a nested unnamed @struct@/@union@ in C).
 \begin{lstlisting}
 enum( char * ) Names { /* as above */ };
 …
 \end{tabular}
 \end{cquote}
 Note, the validity of calls is the same for call-by-reference as for call-by-value, and const restrictions are the same as for other types.
+Note, the validity of calls is the same for call-by-reference as for call-by-value, and @const@ restrictions are the same as for other types.
 \subsection{Enumeration Pseudo-functions}
 Pseudo-functions are function-like operators that do not result in any run-time computations, i.e., like @sizeof@.
+Pseudo-functions are function-like operators that do not result in any run-time computations, i.e., like @sizeof@, @offsetof@, @typeof@.
 Often a call to a pseudo-function is substituted with information extracted from the symbol table at compilation time, like storage size or alignment associated with the underlying architecture..
-\subsubsection{Enumerator Attributes}
 The attributes of an enumerator are accessed by pseudo-functions @position@, @value@, and @label@.
 \begin{lstlisting}
+@***@int jane_pos = position( Names.Jane );   $\C{// 2}$
+@***@char * jane_value = value( Names.Jane ); $\C{// "JANE"}$
+@***@char * jane_label = label( Names.Jane ); $\C{// "Jane"}$
+\end{lstlisting}
+% An instance of \CFA-enum (denoted as @<enum_instance>@) is a label for the defined enum name.
+% The label can be retrieved by calling the function @label( <enum_instance> )@.
+% Similarly, the @value()@ function returns the value used to initialize the \CFA-enum.
+\subsubsection{\lstinline{switch/choose} Statement}
+An intuitive use of enumerations is with the \CFA @switch@/@choose@ statement, where @choose@ performs an implict @break@ rather than a fall-through at the end of a @case@ clause.
+@***@int jane_pos = @position@( Names.Jane );   $\C{// 2}$
+@***@char * jane_value = @value@( Names.Jane ); $\C{// "JANE"}$
+@***@char * jane_label = @label@( Names.Jane ); $\C{// "Jane"}$
+sout | @label@( Names.Jane ) | @value@( Names.Jane );
+\end{lstlisting}
+Note the ability to print both enumerator label and value.
+\subsection{Enumerator Position or Value}
+Enumerators can be used in multiple contexts.
+In most programming languages, an enumerator is implicitly converted to its value (like a typed macro substitution).
+However, enumerator synonyms and typed enumerations make this implicit conversion to value incorrect in some contexts.
+In these contexts, a programmer's initition assumes an implicit conversion to postion.
+For example, an intuitive use of enumerations is with the \CFA @switch@/@choose@ statement, where @choose@ performs an implict @break@ rather than a fall-through at the end of a @case@ clause.
+\begin{cquote}
 \begin{lstlisting}
 enum Count { First, Second, Third, Fourth };
 Count e;
 \end{lstlisting}
-\begin{cquote}
 \begin{tabular}{ll}
 \begin{lstlisting}
 choose( e ) {
         case @First@: ...;
 …
+&
 \begin{lstlisting}
+// rewrite
 choose( @value@( e ) ) {
         case @value@( First ): ...;
 …
 \end{tabular}
 \end{cquote}
 Here, the intuitive implementation on the right uses the value of the enumeration and enumerators.
+Here, the intuitive code on the left is implicitly transformed into the statndard implementation on the right, using the value of the enumeration variable and enumerators.
 However, this implementation is fragile, e.g., if the enumeration is changed to:
 \begin{lstlisting}
 enum Count { First, Second, Third @= First@, Fourth };
 \end{lstlisting}
+which make @Third == First@ and @Fourth == Second@, causing duplicase @case@ clauses.
+To better match with programmer intuition, \CFA uses a more robust implementation form when the type of a @switch@ expression is an enumeration.
+which make @Third == First@ and @Fourth == Second@, causing a compilation error because of duplicase @case@ clauses.
+To better match with programmer intuition, \CFA toggles between value and position semantics depneding on the language context.
+For conditional clauses and switch statments, \CFA uses the robust position implementation.
 \begin{lstlisting}
 choose( @position@( e ) ) {
 …
 \subsection{\CC}
+\CC is backwards compatible with C, so it inherited C's enumerations, except there is no implicit conversion from an integral value to an enumeration;
+hence, the values in a \CC enumeration can only be its enumerators (without a cast).
+There is no mechanism to iterate through an enumeration.
+\CC{11} added a scoped enumeration, \lstinline[language=c++]{enum class} (or \lstinline[language=c++]{enum struct}), so the enumerators are local to the enumeration and must be accessed using type qualification, e.g., @Weekday::Monday@.
+\label{s:C++RelatedWork}
+\CC is backwards compatible with C, so it inherited C's enumerations.
+However, the following non-backwards compatible changes have been made.
+\begin{quote}
+.2 Change: \CC objects of enumeration type can only be assigned values of the same enumeration type.
+In C, objects of enumeration type can be assigned values of any integral type. \\
+Example:
+\begin{lstlisting}
+enum color { red, blue, green };
+color c = 1;                                                    $\C{// valid C, invalid C++}$
+\end{lstlisting}
+\textbf{Rationale}: The type-safe nature of C++. \\
+\textbf{Effect on original feature}: Deletion of semantically well-defined feature. \\
+\textbf{Difficulty of converting}: Syntactic transformation. (The type error produced by the assignment can be automatically corrected by applying an explicit cast.) \\
+\textbf{How widely used}: Common.
+\end{quote}
+\begin{quote}
+.2 Change: In \CC, the type of an enumerator is its enumeration.
+In C, the type of an enumerator is @int@. \\
+Example:
+\begin{lstlisting}
+enum e { A };
+sizeof(A) == sizeof(int)                                $\C{// in C}$
+sizeof(A) == sizeof(e)                                  $\C{// in C++}$
+/* and sizeof(int) is not necessary equal to sizeof(e) */
+\end{lstlisting}
+\textbf{Rationale}: In C++, an enumeration is a distinct type. \\
+\textbf{Effect on original feature}: Change to semantics of well-defined feature. \\
+\textbf{Difficulty of converting}: Semantic transformation. \\
+\textbf{How widely used}: Seldom. The only time this affects existing C code is when the size of an enumerator is taken.
+Taking the size of an enumerator is not a common C coding practice.
+\end{quote}
+Hence, the values in a \CC enumeration can only be its enumerators (without a cast).
+While the storage size of an enumerator is up to the compiler, there is still an implicit cast to @int@.
+\begin{lstlisting}
+enum E { A, B, C };
+E e = A;
+int i = A;   i = e;                                             $\C{// implicit casts to int}$
+\end{lstlisting}
+\CC{11} added a scoped enumeration, \lstinline[language=c++]{enum class} (or \lstinline[language=c++]{enum struct}), so the enumerators are local to the enumeration and must be accessed using type qualification.
+\begin{lstlisting}[language=c++,{moredelim=**[is][\color{red}]{@}{@}}]
+enum class E { A, B, C };
+E e = @E::@A;                                                   $\C{// qualified enumerator}$
+e = B;                                                                  $\C{// B not in scope}$
+\end{lstlisting}
 \CC{20} supports unscoped access with a \lstinline[language=c++]{using enum} declaration.
-For both unscoped and scoped enumerations, the underlying type is an implementation-defined integral type large enough to hold all enumerated values; it does not have to be the smallest possible type.
-In \CC{11}, the underlying integral type can be explicitly specified:
 \begin{lstlisting}[language=c++,{moredelim=**[is][\color{red}]{@}{@}}]
+enum class RGB : @long@ { Red, Green, Blue };
+enum class rgb : @char@ { Red = 'r', Green = 'g', Blue = 'b' };
+enum class srgb : @signed char@ { Red = -1, Green = 0, Blue = 1 };
+RGB colour1 = @RGB::@Red;
+rgb colour2 = @rgb::@Red;
+srgb colour3 = @srgb::@Red;
+\end{lstlisting}
+enum class E { A, B, C };
+@using enum E;@
+E e = A;                                                                $\C{// direct access}$
+e = B;                                                                  $\C{// direct access}$
+\end{lstlisting}
+\CC{11} added the ability to explicitly declare the underlying integral type for \lstinline[language=c++]{enum class}.
+\begin{lstlisting}[language=c++,{moredelim=**[is][\color{red}]{@}{@}}]
+enum class RGB @: long@ { Red, Green, Blue };
+enum class rgb @: char@ { Red = 'r', Green = 'g', Blue = 'b' };
+enum class srgb @: signed char@ { Red = -1, Green = 0, Blue = 1 };
+\end{lstlisting}
+There is no implicit conversion from the \lstinline[language=c++]{enum class} type and to its type.
+\begin{lstlisting}[language=c++,{moredelim=**[is][\color{red}]{@}{@}}]
+rgb crgb = rgb::Red;
+char ch = rgb::Red;   ch = crgb;                $\C{// disallowed}$
+\end{lstlisting}
+Finally, there is no mechanism to iterate through an enumeration nor use the enumeration type to declare an array dimension.
 \subsection{Go}

Note: See TracChangeset for help on using the changeset viewer.

Context Navigation

Changeset d63746f

Legend:

doc/proposals/enum.tex

Download in other formats: