\chapter{Conclusion}

This thesis performed a detailed examination of the three most important high-level containers in many programming languages: array, linked-list, and string.
The goal of the work is to make containers easier to use, performant and safer.
Since some subset of these three containers are used in almost every program in every programming language, this is a laudable goal.
Accomplishing this goal in C is difficult because these features are poorly designed.
In contrast, \CFA's advanced type system and language features plus my critical design choices made it possible to provide better support with significant safety.
The result is application code that is easier to write, understand, maintain, and significantly safer from hacker attach-vectors.
Finally, the performance sections for each container demonstrated that safety does not have to reduce performance, \ie rolling-your-own container is now an excuse not a reason.


\section{Arrays}

The key takeaway for arrays is that the type system must be extended to properly manage array bounds (dimensions) to safely pass arrays to (polymorphic) functions.
By adding a special kind of template constant to \CFA, @[N]@, the type system understands array bounds and implicitly associates these bounds with array instances, statically and dynamically, throughout the programming language.
Array overruns are no longer possible because all subscripting is checked, as in other modern languages.
Subscript checking can be implicitly elided when the compiler is given sufficient information to determine the subscript variable is always in bounds, giving performant execution.
Indirectly, simple and complex VLA's reduce heap allocation resulting in better performance (up to an order of magnitude in comparisons with @std::vector@) and no contention in concurrent programs.
Any reduction of dynamic allocation is always a safety benefit.
Finally, language subarray slicing of higher-dimensional arrays is also a powerful and safety critical feature versus programmers attempting it themselves.


\section{Lists}

The key takeaway for lists is that intrusive lists can be made easy to use, performant by eliminating implicit memory allocation, and able to simulate wrapped lists, whereas wrapped lists cannot simulate intrusive lists.
As well, the \CFA list-API eliminates many frustrating and error-prone requirements with \CC STL lists, \eg, a node can be returned and removed in a single operation (no 2-step @front@/@pop@), and an arbitrary node can be added/removed without the need for an iterator.
As for \CC, the \CFA list API is powerful enough to reduce almost all common C list errors, substantially increasing program safety.


\section{Strings}

The key takeaway for strings is that providing powerful and safe block-operations for manipulating strings is more important than ultra-level performance.
Manipulating strings is always going to be expensive because of their dynamic variable sizing, as the hardware rarely has string-level operations, possibly only move and compare.
The new \CFA string API is a very expressive set of safe string operations for composing, comparing, and decomposing arbitrary length strings, include complex reading and printing operations.
All low-level mechanisms for working with string, in any programming language, are error-prone in correctness and safety (back to working with arrays).
Providing string lengths is also a significant safety improvement, while still working with compiler null-terminate string constants (as for \CC).
As well, overloading C string operations to work with \CFA strings provides a safe vector for updating existing C programs manipulating strings.
Finally, creating bespoke storage management for strings has the advantage of faster, more compact storage management due to string sharing, at the cost of additional external fragmentation between the string and general heap.
With the large amounts of available memory, this approach is a viable tradeoff.


\section{Future Work}

All three forms of containers presented in this work are in their nascence, both in design and implementation.
This work provides the foundation for future \CFA students to add more functionality along with robust and performant implementations.
Completing the syntax change from @array@ to C-style for dimensions and subscripts is an important first step to fit with C-programmer expectation resulting in faster adoption.
Also, adding a panoply of additional intrusive lists, \eg stack, queue, dequeue, \etc, is needed to complement the @list@ structure.
And once the RAII problem in \CFA is fixed, the two part string implementation can be merged into a single form, possibly with even better performance.
I left all the infrastructure to accomplish these task;
they just need time to complete.