source: doc/rob_thesis/conclusions.tex @ 7493339

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

Conclusion paragraphs.

\section{Future Work}

\subsection{Constructors and Destructors}
% TODO: discuss move semantics; they haven't been implemented, but could be. Currently looking at alternative models.

% TODO: discuss exceptions

% TODO: fix return value destruction in full compiler

% TODO: once deleted functions are added, unions can have deleted standard functions, like C++11 (may not need to mention this again...)

% TODO: better study and fix the ways @= objects interact with the rest of the world (e.g. provide @= equivalent for assignment, or otherwise have @= objects default to using intrinsic/autogen ops?)



\subsection{Tuples}

% TODO: named return values are not currently implemented in CFA - tie in with named tuples?

% TODO: tuples are allowed in expressions, exact meaning is defined by operator overloading (e.g. can add tuples). An important caveat to note is that it is currently impossible to allow adding two triples but prevent adding a pair with a quadruple (single flattening/structuring conversions are implicit, only total number of components matters). May be able to solve this with more nuanced conversion rules

\subsection{Variadic Functions}
% TODO: look into 'nicer' expansion syntax

% TODO: consider more sophisticated argument matching algorithms, e.g. forall(ttype Params) void f(Params, Params); f(1,2); f(1,2,3,4); => f([1], [2]); f([1,2], [3,4]); => okay if Params can be bound to a type that is consistent throughout the expression's type