3 ms·
I am very confused by the definition of type erasure which is being used in this work. As a type theorist, my working definition is "terms which have types ins
by jonsterling 12y ago
I am very confused by the definition of type erasure which is being used in this work.
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++.
- subb 12y agoWhen 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.
- jonsterling 12y agoYes, 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.
- Sharlin 12y agoNot 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.