\chapter{Conclusion}
\label{c:conclusion}

This work aims to extend the simple and unsafe enumeration type in the C programming language into a complex and safe enumeration type in the \CFA programming language while maintaining backward compatibility with C.
Within this goal, the new \CFA enumeration should align with the analogous enumeration features in other languages to match modern programming expectations.
Hence, the \CFA enumeration features are borrowed from a number of programming languages, but engineered to work and play with \CFA's type system and feature set.

Strong type-checking of enumeration initialization and assignment provides additional safety, ensuring an enumeration only contains its enumerators.
Overloading and scoping of enumerators significantly reduces the naming problem, providing a better software-engineering environment, with fewer name clashes and the ability to disambiguate those that cannot be implicitly resolved.
Typed enumerations solve the data-harmonization problem, increasing safety through better software engineering.
Moreover, integrating enumerations with existing control structures provides a consistent upgrade for programmers and a succinct and secure mechanism to enumerate with the new loop-range feature.
Generalization and reuse are supported by incorporating the new enumeration type using the \CFA trait system.
Enumeration traits define the meaning of an enumeration, allowing functions to be written that work on any enumeration, such as the reading and printing of an enumeration.
With advanced structural typing, C enumerations can be extended so they work with all of the enumeration features, providing for legacy C code to be moved forward into the modern \CFA programming domain.
Finally, the \CFA project's test suite has been expanded with multiple enumeration feature tests with respect to implicit conversions, control structures, inheritance, interaction with the polymorphic types, and the features built on top of enumeration traits.
These tests ensure future \CFA work does not accidentally break the new enumeration system.

In summary, the new \CFA enumeration mechanisms achieve the initial goals, providing C programmers with an intuitive enumeration mechanism for handling modern programming requirements.


\section{Future Work}

The following are ideas to improve and extend the work in this thesis.
\begin{enumerate}
\item
There are still corner cases being found in the current \CFA enumeration implementation.
Fixing some of these corner cases requires changes to the \CFA resolver or extensions to \CFA. %, like compile-time constant-expression evaluation.
When these changes are made, it should be straightforward to update the \CFA enumeration implementation to work with them.

\item
Currently, some aspects of the enumeration trait system require explicitly including the file \lstinline[deletekeywords={enum}]{enum.hfa}, which can lead to problems.
It should be possible to have this file included implicitly by updating the \CFA prelude.
\item
There are multiple \CFA features being developed in parallel with enumerations.
Two closely related features are iterator and namespace.
Enumerations may have to be modified to dovetail with these features.
For example, enumerating with range loops does not align with the current iterator design, so some changes will be necessary.

\item
C already provides @const@-style aliasing using the \emph{unnamed} enumerator \see{\VRef{s:TypeName}}, even if the name @enum@ is misleading (@const@ would be better).
Given the existence of this form, it is conceivable to extend it with types other than @int@.
\begin{cfa}
enum { Size = 20u, PI = 3.14159L, Jack = L"John" };
\end{cfa}
which matches with @const@ aliasing in other programming languages.
Here, the type of the enumerator is the type of the initialization constant, \eg @typeof( 20u )@ for @Size@ implies @unsigned int@.
Auto-initialization is restricted to the case where all constants are @int@, matching with C.
As seen in \VRef{s:EnumeratorTyping}, this feature is just a shorthand for multiple typed-enumeration declarations.
\begin{cfa}
enum( unsigned int ) { Size = 20u };
enum( long double ) { PI = 3.14159L };
enum( wchar_t * ) { Jack = L"John" };
\end{cfa}

\item
Currently, enumeration scoping is all or nothing. In some cases, it might be useful to
increase the scoping granularity to individual enumerators.
\begin{cfa}
enum E1 { @!@A, @^@B, C };
enum E2 @!@ { @!@A, @^@B, C };
\end{cfa}
Here, @'!'@ means the enumerator is scoped, and @'^'@ means the enumerator is unscoped.
For @E1@, @A@ is scoped; @B@ and @C@ are unscoped.
For @E2@, @A@, and @C@ are scoped; @B@ is unscoped.
Finding a use case is important to justify this extension.

\item
An extension mentioned in \VRef{s:Ada} is using @typedef@ to create an enumerator alias.
\begin{cfa}
enum( int ) RGB { @Red@, @Green@, Blue };
enum( int ) Traffic_Light { @Red@, Yellow, @Green@ };
typedef RGB.Red OtherRed; // alias
\end{cfa}

\item
Label and values arrays are auxiliary data structures that are always generated for \CFA enumeration, which is a program overhead when unused. 
It might be possible to provide a new syntax or annotation for a \CFA enumeration definition indicating these arrays are not used.
Therefore, \CFA does not generated them.
@label@ can still be used on an enumeration constant, as the call reduces to a @char *@ constant expression that holds the name of the enumerator.
But calls on an enumeration variable, generate a compile-time error.
The best alternative is for the linker to discard these arrays if unused.

\item
The \CFA enumeration has limitations with separate compilation.
Consider the following:
\begin{cquote}
\setlength{\tabcolsep}{20pt}
\begin{tabular}{@{}ll@{}}
\begin{cfa}
enum C_Codec {
	FIRST_VIDEO = 0,
	VP8 = 0,
	VP9,
	LAST_VIDEO,

	FIRST_AUDIO = 64,
	VORBIS = 64,
	OPUS,
	LAST_AUDIO
};
\end{cfa}
&
\begin{cfa}
enum( int ) CFA_Codec {
	FIRST_VIDEO = 0,
	VP8 = 0,
	VP9,
	LAST_VIDEO,

	FIRST_AUDIO = 64,
	VORBIS = 64,
	OPUS,
	LAST_AUDIO
};
\end{cfa}
\\
\begin{cfa}
C_Codec c_code = OPUS;
CFA_Codec cfa_code = OPUS;
\end{cfa}
\end{tabular}
\end{cquote}
@c_code@ has value 65, the integral value of @c_code.OPUS@, while @cfa_code@ has value 6, the position of @CFA_Codec.OPUS@.

If the enumerator @AV1@ is inserted in @C_Codec@ and @CFA_Codec@,
\begin{cquote}
\setlength{\tabcolsep}{20pt}
\begin{tabular}{@{}ll@{}}
\begin{cfa}
enum C_Codec {
	FIRST_VIDEO = 0,
	VP8 = 0,
	VP9,
	@AV1@,
	LAST_VIDEO,

	FIRST_AUDIO = 64,
	VORBIS = 64,
	OPUS,
	LAST_AUDIO
};
\end{cfa}
&
\begin{cfa}
enum( int ) CFA_Codec {
	FIRST_VIDEO = 0,
	VP8 = 0,
	VP9,
	@AV1@,
	LAST_VIDEO,

	FIRST_AUDIO = 64,
	VORBIS = 64,
	OPUS,
	LAST_AUDIO
};
\end{cfa}
\end{tabular}
\end{cquote}
the assignments still result in @c_code@ with value 65, but @cfa_code@ is now 7.
For \CFA, if all translation units including @CFA_Codec@ are not recompiled, some could assign the old 6 and some the new 7, while partially compiled C translation units all continue to assign 65.

For \CFA to achieve the same behaviour for positions as C does with value for partial recompilation, enumeration positions could be represented as @const@ declarations with corresponding @extern@ declarations in the include file.
\begin{cquote}
\setlength{\tabcolsep}{20pt}
\begin{tabular}{@{}ll@{}}
\begin{cfa}
const int FIRST_VIDEO_posn = 0;
const int VP8_posn = 1;
const int VP9_posn = 2;

const int LAST_VIDEO_posn = 3;
const int FIRST_AUDIO_posn = 4;
const int VORBIS_posn = 5;
const int OPUS_posn = 6;
const int LAST_AUDIO_posn = 7;
\end{cfa}
&\begin{cfa}
const int FIRST_VIDEO_posn = 0;
const int VP8_posn = 1;
const int VP9_posn = 2;
const int AV1_posn = 3;
const int LAST_VIDEO_posn = 4;
const int FIRST_AUDIO_posn = 5;
const int VORBIS_posn = 6;
const int OPUS_posn = 7;
const int LAST_AUDIO_posn = 8;
\end{cfa}
\end{tabular}
\end{cquote}
Then the linker always uses the most recent object file with the up-to-date positions.
However, this implementation means the equivalent of a position array is generated using more storage.
\end{enumerate}