On 12/14/2013 12:14 PM, Andrey Semashev wrote:

On Sat, Dec 14, 2013 at 8:56 PM, Peter Dimov wrote:

...

If we're going to call the next release 2.0, we'll be allowed some latitude with respect to breaking changes, so maybe this is the right time to finally remove the Bind placeholders from the global namespace.

This will, however, break many things all around Boost (to say nothing about the outside world), as a quick grep can readily reveal. And, consequently, it will generate a certain amount of work for the maintainers of the affected libraries that, from their point of view, can appear unnecessary.

So I'll need a certain amount of community consensus before going ahead and breaking everyone's code. :-)

So far I had no problems with the global placeholders and used them extensively in my projects. For sure this will cause a lot of headache for me. I'd prefer not making this change, unless there is a compelling reason for it.

The compelling reason is that if it remains in the global namespace no other use of '_n' can be conveniently hoisted into the current scope at the same time via a 'using namespace xxx'. Whereas if it is in its own namespace, as in retrospect it should have been, then the flexibility of hoisting the use of '_n' from whatever library, can be preserved. Its the same as putting any common name into the global namespace from a library, only to have it easily conflict with other uses of the same name. It is to be avoided as a matter of good programming principle. On a practical level other libraries, Boost and otherwise, use the '_n' notation and this has led to problems and numerous complaints in the past because of the bind placeholders being in the global namespace.

The compelling reason is that if it remains in the global namespace no other use of '_n' can be conveniently hoisted into the current scope at the same time via a 'using namespace xxx'. Whereas if it is in its own namespace, as in retrospect it should have been, then the flexibility of hoisting the use of '_n' from whatever library, can be preserved.

+1 As a frequent Boost.Phoenix user (and one who dislikes their 'argN' alternative), I run into this often. Regards, Nate

Chris Brown writes:

On 12/14/13, 8:56 AM, Peter Dimov wrote:

...

If we're going to call the next release 2.0, we'll be allowed some latitude with respect to breaking changes, so maybe this is the right time to finally remove the Bind placeholders from the global namespace.

This will, however, break many things all around Boost (to say nothing about the outside world), as a quick grep can readily reveal. And, consequently, it will generate a certain amount of work for the maintainers of the affected libraries that, from their point of view, can appear unnecessary.

So I'll need a certain amount of community consensus before going ahead and breaking everyone's code. :-)

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

I can't speak for the maintainers, but as someone that would have considerable "outside world" breakage, I'm still very much in support of this. If there were ever a right time to do it (other than from the start of course), it would be 2.0.

Not to mention that C++11 is now truly upon us, anf they have the bind placeholders in `namespace std::placeholders`. Basically, you'd just be aligning with the standard, the way Boost.Thread, Boost.System and others have been. Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)

On Sat, Dec 14, 2013 at 7:58 PM, Marshall Clow wrote:

On Dec 14, 2013, at 3:19 PM, Alexander Lamaison wrote:

...

Chris Brown writes:

...

On 12/14/13, 8:56 AM, Peter Dimov wrote:

...

If we're going to call the next release 2.0, we'll be allowed some latitude with respect to breaking changes, so maybe this is the right time to finally remove the Bind placeholders from the global namespace.

This will, however, break many things all around Boost (to say nothing about the outside world), as a quick grep can readily reveal. And, consequently, it will generate a certain amount of work for the maintainers of the affected libraries that, from their point of view, can appear unnecessary.

+1 The fix for maintainers is trivial and will be more in line with standards. We recently made the update to std::placeholders::_n in our library's backwards compatibility layer, it was well-received and not too much effort. Hey, now that we can do it with pull requests, maybe maintainers won't have to do much work at all!

+1 for getting the placeholders out of the global namespace. On Mon, Dec 16, 2013 at 1:25 AM, Niall Douglas wrote:

On 14 Dec 2013 at 18:56, Peter Dimov wrote:

...

If we're going to call the next release 2.0, we'll be allowed some latitude with respect to breaking changes, so maybe this is the right time to finally remove the Bind placeholders from the global namespace. [snip] So I'll need a certain amount of community consensus before going ahead and breaking everyone's code. :-)

I think improving conformance with standards is the one uncontroversial set of breaking changes Boost can make, and therefore requires no community consensus, just fair warning it's coming.

It's relatively trivial for older libraries in to inject the placeholders namespace into their own local namespace if they need a quick fix anyway, so I'd press ahead as soon as possible here. IMHO of course.

Niall

-- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost