On Sat, Jun 13, 2009 at 12:48 PM, Daniel Frey <d.frey@gmx.de> wrote:
The problem with the approach you described is IMHO that if you allow noncopyable_<T> as an *alternative*, most people will likely ignore it.
I'm not convinced that is a problem. If people ignore it their code will still be correct, it just might make certain objects larger than they need to be, which is no different from the present situation. Those who are aware of the change could now use it instead of either just living with noncopyable as it currently is or handrolling their own noncopyable template. As well, those new to boost who are just being introduced to noncopyable would be able to use the template version from the start, since that's what the documentation would recommend. The added noncopyable_ template wouldn't hurt anyone IMO. On Sat, Jun 13, 2009 at 12:59 PM, Steven Watanabe <watanabesj@gmail.com>wrote:
I don't think this is sufficiently important to warrant a breaking change no matter how obvious the update is.
I'm with Steven on this, I don't think it's important enough for a sudden breaking change, so if a template version were added, the current version should continue to exist at least for a few versions. As well, the current noncopyable is used in at least one other library for a different purpose where there is no need for a template argument, and one would probably just make things confusing (I.E. Boost.Python's class_ template uses it to signal the implementation to suppress registration of to_python conversions, see http://www.boost.org/doc/libs/1_39_0/libs/python/doc/v2/class.html ). I'm fine with just having a template version documented and leaving the non-template version in undocumented (or with a note that it is for legacy code), but if people think it would be necessary to have either the template or the nontemplate, but not both, you could always spread the change across a few versions to make things easier for users and avoid a very sudden breaking change. For instance, you could add the noncopyable_ template for a few versions, deprecating noncopyable but leaving it in. Then, remove the noncopyable spelling completely and have both noncopyable_ and noncopyable be templates, with the underscored version deprecated. Finally, remove the underscore version entirely and be left with noncopyable as a template. Boost.Python would have to be updated accordingly but that wouldn't be much of a problem -- it could either switch to using its own noncopyable tag type or use noncopyable<>, where noncopyable would have an unspecified default. -- -Matt Calabrese