When I frist saw the title of Zach Laine's talk, I was confused too. Type erasure for me is what happens with generics in Java, i.e. type information is discarded after compilation.
In this case, the type is still present at runtime. I saw this technique described as "type safe void*", which is paradoxal to me.
However, I do get the idea behind this, but I think "type erasure" is a wrong name for it.
Re:Type Erasure with Merged Concepts in C++
by jonsterling on Monday October 20, 2014 @01:19AM
(#8480789)
Yes, I think this stuff has nothing to do at all with type erasure. it's very confusing when a well defined concept gets appropriated for something that is very different, and totally unrelated.
Re:Type Erasure with Merged Concepts in C++
by Sharlin on Monday October 20, 2014 @07:17AM
(#8481529)
Not sure about its exact origins, but in the C++ context the usage is pretty well established. AFAIK it was first used to denote the way std::function (then boost::function) is able to hide the actual type of a callable object while retaining type safety.
As a type theorist, my working definition is "terms which have types inside them are turned into terms which do not have types inside them"; this is a process which occurs after types have been checked/inferred, and before execution. This is crucially not something that programmers do: if you take a polymorphic interface and wrap it up in one that doesn't quantify over types, that wasn't type erasure.
But perhaps I have simply misunderstood the code in this post; I'll admit it's been a while since I have read C++.