source: doc/rob_thesis/conclusions.tex @ 17f27d40

%======================================================================
\chapter{Conclusions}
%======================================================================

Adding resource management and tuples to \CFA has been a challenging design, engineering, and implementation exercise.
On the surface, the work may appear as a rehash of similar mechanisms in \CC.
However, every added feature is different than its \CC counterpart, often with extended functionality, better integration with C and its programmers, and always supports separate compilation.
All of these new features are being used by the \CFA development-team to build the \CFA runtime system.

\section{Constructors and Destructors}
\CFA supports the RAII idiom using constructors and destructors.
There are many engineering challenges in introducing constructors and destructors, partially since \CFA is not an object-oriented language.
By making use of managed types, \CFA programmers are afforded an extra layer of safety and ease of use in comparison to C programmers.
While constructors and destructors provide a sensible default behaviour, \CFA allows experienced programmers to declare unmanaged objects to take control of object management for performance reasons.
Constructors and destructors as named functions fit the \CFA polymorphism model perfectly, allowing polymorphic code to use managed types seamlessly.

\section{Tuples}
\CFA can express functions with multiple return values in a way that is simple, concise, and safe.
The addition of multiple-return-value functions naturally requires a way to use multiple return values, which begets tuple types.
Tuples provide two useful notions of assignment: multiple assignment, allowing simple, yet expressive assignment between multiple variables, and mass assignment, allowing a lossless assignment of a single value across multiple variables.
Tuples have a flexible structure that allows the \CFA type-system to decide how to restructure tuples, making it syntactically simple to pass tuples between functions.
Tuple types can be combined with polymorphism and tuple conversions can apply during assertion inference to produce a cohesive feel.

\section{Variadic Functions}
Type-safe variadic functions, with a similar feel to variadic templates, are added to \CFA.
The new variadic functions can express complicated recursive algorithms.
Unlike variadic templates, it is possible to write @new@ as a library routine and to separately compile @ttype@ polymorphic functions.
Variadic functions are statically type checked and provide a user experience that is consistent with that of tuples and polymorphic functions.

\section{Future Work}
\subsection{Constructors and Destructors}
Both \CC and Rust support move semantics, which expand the user's control of memory management by providing the ability to transfer ownership of large data, rather than forcing potentially expensive copy semantics.
\CFA currently does not support move semantics, partially due to the complexity of the model.
The design space is currently being explored with the goal of finding an alternative to move semantics that provides necessary performance benefits, while reducing the amount of repetition required to create a new type, along with the cognitive burden placed on the user.

% One technique being evaluated is whether named return-values can be used to eliminate unnecessary temporaries \cite{Buhr94a}.
% For example,
% \begin{cfacode}
% struct A { ... };
% [A x] f(A x);
% [A y] g(A y);
% [A z] h(A z);

% struct A a1, a2;
% a2 = h(g(f(a1)));
% \end{cfacode}
% Here, since both @f@'s argument and return value have the same name and type, the compiler can infer that @f@ returns its argument.
% With this knowledge, the compiler can reuse the storage for the argument to @f@ as the argument to @g@.  % TODO: cite Till thesis?

Exception handling is among the features expected to be added to \CFA in the near future.
For exception handling to properly interact with the rest of the language, it must ensure all RAII guarantees continue to be met.
That is, when an exception is raised, it must properly unwind the stack by calling the destructors for any objects that live between the raise and the handler.
This can be accomplished either by augmenting the translator to properly emit code that executes the destructors, or by switching destructors to hook into the GCC @cleanup@ attribute \cite[6.32.1]{GCCExtensions}.

The @cleanup@ attribute, which is attached to a variable declaration, takes a function name as an argument and schedules that routine to be executed when the variable goes out of scope.
\begin{cfacode}
struct S { int x; };
void __dtor_S(struct S *);
{
  __attribute__((cleanup(__dtor_S))) struct S s;
} // calls __dtor_S(&s)
\end{cfacode}
This mechanism is known and understood by GCC, so that the destructor is properly called in any situation where a variable goes out of scope, including function returns, branches, and built-in GCC exception handling mechanisms using libunwind.

A caveat of this approach is that the @cleanup@ attribute only permits a function that consumes a single argument of type @T *@ for a variable of type @T@.
This restriction means that any destructor that consumes multiple arguments (\eg, because it is polymorphic) or any destructor that is a function pointer (\eg, because it is an assertion parameter) must be called through a local thunk.
For example,
\begin{cfacode}
forall(otype T)
struct Box {
  T x;
};
forall(otype T) void ^?{}(Box(T) * x); // has implicit parameters

forall(otype T)
void f(T x) {
  T y = x;  // destructor is a function-pointer parameter
  Box(T) z = { x }; // destructor has multiple parameters
}
\end{cfacode}
currently generates the following
\begin{cfacode}
void _dtor_BoxT(  // consumes more than 1 parameter due to assertions
  void (*_adapter_PTT)(void (*)(), void *, void *),
  void (*_adapter_T_PTT)(void (*)(), void *, void *, void *),
  long unsigned int _sizeof_T,
  long unsigned int _alignof_T,
  void *(*_assign_T_PTT)(void *, void *),
  void (*_ctor_PT)(void *),
  void (*_ctor_PTT)(void *, void *),
  void (*_dtor_PT)(void *),
  void *x
);

void f(
  void (*_adapter_PTT)(void (*)(), void *, void *),
  void (*_adapter_T_PTT)(void (*)(), void *, void *, void *),
  long unsigned int _sizeof_T,
  long unsigned int _alignof_T,
  void *(*_assign_TT)(void *, void *),
  void (*_ctor_T)(void *),
  void (*_ctor_TT)(void *, void *),
  void (*_dtor_T)(void *),
  void *x
){
  void *y = __builtin_alloca(_sizeof_T);
  // constructor call elided

  // generic layout computation elided
  long unsigned int _sizeof_BoxT = ...;
  void *z = __builtin_alloca(_sizeof_BoxT);
  // constructor call elided

  _dtor_BoxT(  // ^?{}(&z); -- _dtor_BoxT has > 1 arguments
    _adapter_PTT,
    _adapter_T_PTT,
    _sizeof_T,
    _alignof_T,
    _assign_TT,
    _ctor_T,
    _ctor_TT,
    _dtor_T,
    z
  );
  _dtor_T(y);  // ^?{}(&y); -- _dtor_T is a function pointer
}
\end{cfacode}
Further to this point, every distinct array type will require a thunk for its destructor, where array destructor code is currently inlined, since array destructors hard code the length of the array.

For function call temporaries, new scopes have to be added for destructor ordering to remain consistent.
In particular, the translator currently destroys argument and return value temporary objects as soon as the statement they were created for ends.
In order for this behaviour to be maintained, new scopes have to be added around every statement that contains a function call.
Since a nested expression can raise an exception, care must be taken when destroying temporary objects.
One way to achieve this is to split statements at every function call, to provide the correct scoping to destroy objects as necessary.
For example,
\begin{cfacode}
struct S { ... };
void ?{}(S *, S);
void ^?{}(S *);

S f();
S g(S);

g(f());
\end{cfacode}
would generate
\begin{cfacode}
struct S { ... };
void _ctor_S(struct S *, struct S);
void _dtor_S(struct S *);

{
  __attribute__((cleanup(_dtor_S))) struct S _tmp1 = f();
  __attribute__((cleanup(_dtor_S))) struct S _tmp2 =
    (_ctor_S(&_tmp2, _tmp1), _tmp2);
  __attribute__((cleanup(_dtor_S))) struct S _tmp3 = g(_tmp2);
} // destroy _tmp3, _tmp2, _tmp1
\end{cfacode}
Note that destructors must be registered after the temporary is fully initialized, since it is possible for initialization expressions to raise exceptions, and a destructor should never be called on an uninitialized object.
This requires a slightly strange looking initializer for constructor calls, where a comma expression is used to produce the value of the object being initialized, after the constructor call, conceptually bitwise copying the initialized data into itself.
Since this copy is wholly unnecessary, it is easily optimized away.

A second approach is to attach an accompanying boolean to every temporary that records whether the object contains valid data, and thus whether the value should be destructed.
\begin{cfacode}
struct S { ... };
void _ctor_S(struct S *, struct S);
void _dtor_S(struct S *);

struct _tmp_bundle_S {
  bool valid;
  struct S value;
};

void _dtor_tmpS(struct _tmp_bundle_S * ret) {
  if (ret->valid) {
    _dtor_S(&ret->value);
  }
}

{
  __attribute__((cleanup(_dtor_tmpS))) struct _tmp_bundle_S _tmp1 = { 0 };
  __attribute__((cleanup(_dtor_tmpS))) struct _tmp_bundle_S _tmp2 = { 0 };
  __attribute__((cleanup(_dtor_tmpS))) struct _tmp_bundle_S _tmp3 = { 0 };
  _tmp2.value = g(
    (_ctor_S(
      &_tmp2.value,
      (_tmp1.value = f(), _tmp1.valid = 1, _tmp1.value)
    ), _tmp2.valid = 1, _tmp2.value)
  ), _tmp3.valid = 1, _tmp3.value;
} // destroy _tmp3, _tmp2, _tmp1
\end{cfacode}
In particular, the boolean is set immediately after argument construction and immediately after return value copy.
The boolean is checked as a part of the @cleanup@ routine, forwarding to the object's destructor if the object is valid.
One such type and @cleanup@ routine needs to be generated for every type used in a function parameter or return value.

The former approach generates much simpler code, however splitting expressions requires care to ensure that expression evaluation order does not change.
Expression ordering has to be performed by a full compiler, so it is possible that the latter approach would be more suited to the \CFA prototype, whereas the former approach is clearly the better option in a full compiler.
More investigation is needed to determine whether the translator's current design can easily handle proper expression ordering.

As discussed in Section \ref{s:implicit_copy_construction}, return values are destructed with a different @this@ pointer than they are constructed with.
This problem can be easily fixed once a full \CFA compiler is built, since it would have full control over the call/return mechanism.
In particular, since the callee is aware of where it needs to place the return value, it can construct the return value directly, rather than bitwise copy the internal data.

Currently, the special functions are always auto-generated, except for generic types where the type parameter does not have assertions for the corresponding operation.
For example,
\begin{cfacode}
forall(dtype T | sized(T) | { void ?{}(T *); })
struct S { T x; };
\end{cfacode}
only auto-generates the default constructor for @S@, since the member @x@ is missing the other 3 special functions.
Once deleted functions have been added, function generation can make use of this information to disable generation of special functions when a member has a deleted function.
For example,
\begin{cfacode}
struct A {};
void ?{}(A *) = delete;
struct S { A x; };  // does not generate void ?{}(S *);
\end{cfacode}

Unmanaged objects and their interactions with the managed \CFA environment are an open problem that deserves greater attention.
In particular, the interactions between unmanaged objects and copy semantics are subtle and can easily lead to errors.
It is possible that the compiler should mark some of these situations as errors by default, and possibly conditionally emit warnings for some situations.
Another possibility is to construct, destruct, and assign unmanaged objects using the intrinsic and auto-generated functions.
A more thorough examination of the design space for this problem is required.

Currently, the \CFA translator does not support any warnings.
Ideally, the translator should support optional warnings in the case where it can detect that an object has been constructed twice.
For example, forwarding constructor calls are guaranteed to initialize the entire object, so redundant constructor calls can cause problems such as memory leaks, while looking innocuous to a novice user.
\begin{cfacode}
struct B { ... };
struct A {
  B x, y, z;
};
void ?{}(A * a, B x) {
  // y, z implicitly default constructed
  (&a->x){ ... }; // explicitly construct x
} // constructs an entire A
void ?{}(A * a) {
  (&a->y){}; // initialize y
  a{ (B){ ... } }; // forwarding constructor call
                   // initializes entire object, including y
}
\end{cfacode}

Finally, while constructors provide a mechanism for establishing invariants, there is currently no mechanism for maintaining invariants without resorting to opaque types.
That is, structure fields can be accessed and modified by any block of code without restriction, so while it is possible to ensure that an object is initially set to a valid state, it is not possible to ensure that it remains in a consistent state throughout its lifetime.
A popular technique for ensuring consistency in object-oriented programming languages is to provide access modifiers such as @private@, which provides compile-time checks that only privileged code accesses private data.
This approach could be added to \CFA, but it requires an idiomatic way of specifying what code is privileged.
One possibility is to tie access control into an eventual module system.

\subsection{Tuples}
Named result values are planned, but not yet implemented.
This feature ties nicely into named tuples, as seen in D and Swift.

Currently, tuple flattening and structuring conversions are 0-cost.
This makes tuples conceptually very simple to work with, but easily causes unnecessary ambiguity in situations where the type system should be able to differentiate between alternatives.
Adding an appropriate cost function to tuple conversions will allow tuples to interact with the rest of the programming language more cohesively.

\subsection{Variadic Functions}
Use of @ttype@ functions currently relies heavily on recursion.
\CC has opened variadic templates up so that recursion is not strictly necessary in some cases, and it would be interesting to see if any such cases can be applied to \CFA.

\CC supports variadic templated data-types, making it possible to express arbitrary length tuples, arbitrary parameter function objects, and more with generic types.
Currently, \CFA does not support @ttype@-parameter generic-types, though there does not appear to be a technical reason that it cannot.
Notably, opening up support for this makes it possible to implement the exit form of scope guard (see section \ref{s:ResMgmt}), making it possible to call arbitrary functions at scope exit in idiomatic \CFA.