<div dir="ltr">It might be useful to look at how Apple's 'Dylan' language does this. It's all been defined and implemented and in use by the (admittedly small) community for 15 - 20 years.  CMU's 'd2c' compiler, in particular, uses these to produce code with speed almost indistinguishable from C.<div><br><div><br></div><div>A 'sealed' class is precisely one that can not have subclasses defined outside of its library (compilation unit)</div><div><br></div><div><a href="http://opendylan.org/books/drm/Declaring_Characteristics_of_Classes">http://opendylan.org/books/drm/Declaring_Characteristics_of_Classes</a><br></div><div><br></div><div>Define Sealed Domain may also be of interest:</div><div><br></div><div><a href="http://opendylan.org/books/drm/Define_Sealed_Domain">http://opendylan.org/books/drm/Define_Sealed_Domain</a><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 28, 2015 at 10:05 PM, David Chisnall <span dir="ltr"><<a href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank">David.Chisnall@cl.cam.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 27 Jan 2015, at 17:13, Philip Reames <<a href="mailto:listmail@philipreames.com">listmail@philipreames.com</a>> wrote:<br>
><br>
> Given we have a large number of compiler authors and contributors to the C++ language spec, it seems really odd to me that we can't solve this problem in a more elegant way. The tagged-dispatch as a sealed world replacement for virtual dispatch is one that comes up on a pretty regular basis.  Might it be time to figure out how to generalize this and propose either a clang extension or a language mechanism for some future version of C++?<br>
<br>
</span>One of the motivations for being able to mark a class as final in Java was to allow compilers to perform optimisations on the assumption that there would never be any subclasses (I don't believe any modern JVMs take advantage of this as it's mostly only useful to AoT compilers, but maybe ART does).  For this idiom, the guarantee that you want is something slightly broader than final, it's that, at some known point, all subclasses will be visible to the optimiser.  This is a bit difficult to do in the files-are-approximately-compilation-units model, but a bit easier with LTO (though re-inferring enough information to do devirtualisation at this level is a bit tricky).<br>
<br>
C++, at the language level, unfortunately has no notion of a shared library.  This is very problematic in some places in C++11 (the semantics for when constructors and destructors are run for thread_local objects in the presence of multiple threads and library loading and unloading are very poorly defined) and also makes it difficult to have a package-final or similar to indicate that no subclasses outside of this library are permitted.<br>
<br>
Or, if the goal is to put a little bit more burden on the programmer but give greater flexibility in implementations, I believe that one of the people in this thread is the head of the reflection subcommittee in WG21, so may already be reviewing proposals that would make it easier to implement generically...<br>
<span class="HOEnZb"><font color="#888888"><br>
David<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br></div>