Changes in doc/rob_thesis/conclusions.tex [0111dc7:12d3187]

File:

• doc/rob_thesis/conclusions.tex (modified) (3 diffs)

doc/rob_thesis/conclusions.tex

@@ -6 +6 @@
 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.
+All of these new features are being used extensively by the \CFA development-team to build the \CFA runtime system.
+In particular, the concurrency system is built on top of RAII, library functions @new@ and @delete@ are used to manage dynamically allocated objects, and tuples are used to provide uniform interfaces to C library routines such as @div@ and @remquo@.
 
 \section{Constructors and Destructors}
@@ -245 +246 @@
 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.
+This approach could be added to \CFA, but it requires an idiomatic way of specifying what code is privileged and what data is protected.
 One possibility is to tie access control into an eventual module system.
+
+\begin{sloppypar}
+The current implementation of implicit subobject-construction is currently an all-or-nothing check.
+That is, if a subobject is conditionally constructed, \eg within an if-statement, no implicit constructors for that object are added.
+\begin{cfacode}
+struct A { ... };
+void ?{}(A * a) { ... }
+
+struct B {
+  A a;
+};
+void ?{}(B * b) {
+  if (...) {
+    (&b->a){};  // explicitly constructed
+  } // does not construct in else case
+}
+\end{cfacode}
+This behaviour is unsafe and breaks the guarantee that constructors fully initialize objects.
+This situation should be properly handled, either by examining all paths and inserting implicit constructor calls only in the paths missing construction, or by emitting an error or warning.
+\end{sloppypar}
 
 \subsection{Tuples}
@@ -252 +273 @@
 This feature ties nicely into named tuples, as seen in D and Swift.
 
-Currently, tuple flattening and structuring conversions are 0-cost.
+Currently, tuple flattening and structuring conversions are 0-cost conversions in the resolution algorithm.
 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.