source: doc/theses/jiada_liang_MMath/Cenum.tex@ b723b63

\chapter{C Enumeration in \texorpdfstring{\CFA}{Cforall}}

\CFA supports legacy C enumeration using the same syntax for backward compatibility.
A C-style enumeration in \CFA is called a \newterm{C Enum}.
The semantics of the C Enum are mostly consistent with C with some restrictions.
The following sections detail all of my new contributions to enumerations in C.


\section{Visibility}
\label{s:CVisibility}

In C, unscoped enumerators present a \newterm{naming problem} when multiple enumeration types appear in the same scope with duplicate enumerator names.
\begin{cfa}
enum E1 { First, Second, Third, Fourth };
enum E2 { @Fourth@, @Third@, @Second@, @First@ }; $\C{// same enumerator names}$
\end{cfa}
There is no mechanism in C to resolve these naming conflicts other than renaming one of the duplicates, which may be impossible if the conflict comes from system include-files.

The \CFA type-system allows extensive overloading, including enumerators. For example, enumerator First from E1 can exist at the scope as First from E2.
Hence, most ambiguities among C enumerators are implicitly resolved by the \CFA type system, possibly without any programmer knowledge of the conflict.
In addition, C Enum qualification is added, exactly like aggregate field-qualification, to disambiguate.
\VRef[Figure]{f:EnumeratorVisibility} shows how resolution, qualification, and casting are used to disambiguate situations for enumerations @E1@ and @E2@.

\begin{figure}
\begin{cfa}
E1 f() { return Third; }                                $\C{// overload functions with different return types}$
E2 f() { return Fourth; }
void g( E1 e );
void h( E2 e );
void foo() {                                                    $\C{// different resolutions and dealing with ambiguities}$
        E1 e1 = First;   E2 e2 = First;         $\C{// initialization}$
        e1 = Second;   e2 = Second;                     $\C{// assignment}$
        e1 = f();   e2 = f();                           $\C{// function return}$
        g( First );   h( First );                       $\C{// function argument}$
        int i = @E1.@First + @E2.@First;        $\C{// disambiguate with qualification}$
        int j = @(E1)@First + @(E2)@First;      $\C{// disambiguate with cast}$
}
\end{cfa}
\caption{Enumerator Visibility and Disambiguating}
\label{f:EnumeratorVisibility}
\end{figure}

Aside, name shadowing in \CFA only happens when a name has been redefined with the \emph{exact} same type.
Because an enumeration define its type and enumerators in one definition, shadowing an enumerator is not possible, \ie it is impossible to have another @First@ with same type @E1@.


\section{Scoping}

A C Enum can be scoped, using @'!'@, so the enumerator constants are not projected into the enclosing scope.
\begin{cfa}
enum Week @!@ { Mon, Tue, Wed, Thu = 10, Fri, Sat, Sun };
enum RGB @!@ { Red, Green, Blue };
\end{cfa}
Now, the enumerators \emph{must} be qualified with the associated enumeration type.
\begin{cfa}
Week week = @Week.@Mon;
week = @Week.@Sat;
RGB rgb = @RGB.@Red;
rgb = @RGB.@Blue;
\end{cfa}
% with feature unimplemented
It is possible to introduce enumerators from a scoped enumeration to a block scope using the \CFA @with@ auto-qualification clause/statement (see also \CC \lstinline[language=c++]{using enum} in Section~\ref{s:C++RelatedWork}).
\begin{cfa}
with ( @Week@, @RGB@ ) {                                $\C{// type names}$
         week = @Sun@;                                          $\C{// no qualification}$
         rgb = @Green@;
}
\end{cfa}
As in Section~\ref{s:CVisibility}, opening multiple scoped enumerations in a @with@ can result in duplicate enumeration names, but \CFA implicit type resolution and explicit qualification/casting handle this localized scenario.


\section{Type Safety}
\label{s:TypeSafety}

As in Section~\ref{s:Usage}, C's implicit bidirectional conversion between enumeration and integral type raises a safety concern.
In \CFA, the conversion is changed to unidirectional: an enumeration can be implicitly converted into an integral type, with an associated @safe@ conversion cost.
However, an integral type cannot be implicitly converted into a C enumeration because the conversion cost is set to @infinity@.
\begin{cfa}
enum Bird { Penguin, Robin, Eagle };
enum Fish { Shark, Salmon, Whale };

int i = Robin;                                                  $\C{// allow, implicitly converts to 1}$
enum Bird @bird = 1;@                                   $\C{// disallow }$
enum Bird @bird = Shark;@                               $\C{// disallow }$
\end{cfa}
It is now up to the programmer to insert an explicit cast to force the assignment.
\begin{cfa}
enum Bird bird = @(Bird)@1;
enum Bird bird = @(Bird)@Shark
\end{cfa}

Note, \CC has the same safe restriction and provides the same workaround cast:
\begin{cquote}
\begin{description}[leftmargin=*,topsep=0pt,itemsep=0pt,parsep=0pt]
\item[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{cfa}
enum color { red, blue, green };
color c = 1;                            $\C{// valid C, invalid \CC}$
\end{cfa}
\item[Rationale:] The type-safe nature of \CC.
\item[Effect on original feature:] Deletion of semantically well-defined feature.
\item[Difficulty of converting:] Syntactic transformation. (The type error produced by the assignment can be
automatically corrected by applying an explicit cast.)
\item[How widely used:] Common.
\end{description}
\hfill ISO/IEC 14882:1998 (\CC Programming Language Standard)~\cite[C.1.5.7.2.5]{ANSI98:C++}
\end{cquote}