On 15 Nov 2013 at 13:34, Steven Watanabe wrote:
problem because of so much preexisting usage. It's an established idiom, and that's that: in my opinion TypeIndex has the right to use established idioms if they are currently safe with all possible present compiler technologies as implied by the present C++ standard.
I don't agree that this is an idiom. I know that Boost.Move uses it, but I'm not aware of any other Boost library that does. Boost.Move is not nearly as problematic, because it only uses this in the fallback for C++03. It will eventually be phased out in C++11.
Let me clarify myself, as I've suddenly realised I was being unclear: Let there be a DLL exporting function: struct Foo { ... }; struct MoreFoo : Foo { ... }; MoreFoo &convert(Foo &in) { return static_cast<MoreFoo &>(in); // upcast to more derived type } Let there be another DLL in which we do: MoreFoo a; auto b=convert(a); // legal Foo c; auto d=convert(c); // not legal Where I was coming from was the case of the first DLL: there the compiler cannot know if the inbound Foo & originally came from a MoreFoo or not. It simply must proceed as if it did. That's what I meant by a very common idiom - we write code like the first DLL all the time where we cannot possibly know if we are doing undefined behaviour, because that's on the caller, not us. The shared library boundary makes avoiding this impossible. If we implement C++ Modules, then it all gets much more interesting, and that's what I was referring to about this idiom being a problem for future C++ features. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/