On Sun, Jan 27, 2013 at 6:19 PM, Alec Teal <a.t...@warwick.ac.uk> wrote: > To some up again (I've kept the quotes so it can be seen what's already been > talked about) I propose something that is almost identical to a typedef as > it exists now, all behaviour of this hard typedef is almost identical > except: > > 1) the "hard" type is never implicitly 'cast' to anything else of the same > actual type (a BookId may never become an int implicitly)
So that's like a "private" opaque alias in n3515. > 2) the "hard" type may be used in overloading (building on the 'may not be > implicitly cast' a call to f(someBook) will never resolve to f(int), only to > f(BookId) Also the same as a private opaque aias in n3515. > Because it is to behave like a typedef the c-style cast isn't actually a > cast at all, it is a way of telling the compiler you intend to use the > hard-typed variable as you have written. There is no actual cast because > it's a kind of typedef the underlying data is by definition the same. If the > compiler didn't complain when you tried to use a BookId as an int or > visa-versa that would defeat the purpose. the c-style cast of "int x = (int) > some_book;" or whatever is not a cast (I'm saying the same thing again, > sorry) it's just telling the compiler "Yes, I mean to write this" That's a cast -- an explicit request in code for a type conversion. The fact that it's a pure compile-time operation and a no-op at runtime has no bearing on whether it "is a cast", just as we can static_cast beween enumerators and integers today with no run-time cost. One of the purposes of casts is to tell the compiler "Yes, I mean to write this", and it's common for casts to be purely compile-time operations. n3515 is also explicit that the permitted conversions have no run-time cost. Is there anything that you propose that a "private opaque alias" from n3515 does not provide? -- James
