source: doc/theses/jiada_liang_MMath/conclusion.tex @ 90e7a2f

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

The goal of this work is 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 backwards 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 burrowed from a number of programming languages, but engineered to work and play with \CFA's type system and feature set.

Additional safety is provided by strong type-checking of enumeration initialization and assignment, 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.
As well, 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 an enumeration.
Using advanced duck typing, existing 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, I expanded the \CFA project's test-suite with multiple enumeration features 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 accidently break the new enumeration system.

The conclusion is that the new \CFA enumeration mechanisms achieves the initial goals, providing C programmers with an intuitive enumeration mechanism for handling modern programming requirements.


\section{Future Work}

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.

Currently, some aspects of the enumeration trait system require explicitly including file @enum.hfa@, which easily leads to problems.
It should be possible to have this file included implicitly by updating the \CFA prelude.

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}