On Thu, Jun 18, 2009 at 9:01 PM, David Abrahams <dave@boostpro.com> wrote:
Ironic, since in Sean's world, all types are copyable :-)
Ha, yes, and I even tend to agree. I look at noncopyable as more of a utility to prevent people from copying either because the operations just haven't yet been implemented or because there is currently no practical use-case for it to be called. In a perfect world, every type would be regular and it would take no time or effort to make them such, but the world is sadly not perfect. On Thu, Jun 18, 2009 at 9:50 PM, David Abrahams <dave@boostpro.com> wrote:
I'm not really sure there's a better name for what it does. Why should a different tag be used?
It's not that important to me and is more subjective than anything else. I don't see any issue with the name, more that it's reusing a type intended for a technically different purpose _because_ of that name (a noncopyable tag type with the same name in ::boost::python for instance would be fine if not potentially confusing). The use of noncopyable in Boost.Python does not directly relate to its documented purpose if you read the documentation of noncopyable. Again, it's really just used because of the name rather than the type's actual purpose. If noncopyable were a more complicated type or if its use were vastly different from its use in class_, I'd see it as an actual problem, but given that it's just a simple little utility type that doesn't even really depend on anything, there is no practical reason why it shouldn't be used. I doubt it even causes any confusion so it's just more of a philosophical issue at that point and I wouldn't use that alone as a rationale for a change. The only real issue as I see it is that if noncopyable becomes a template, it is a little bit less clear as to what exactly should be done for class_ to reflect the change. -- -Matt Calabrese