Release Managers: permission to merge small feature to release?
I have a ticket <https://svn.boost.org/trac/boost/ticket/7652> asking for compile-time checked access to elements of a boost::array. I have implemented a specialization of boost::get (and for c++11, std::get) that does this, and it's been on the trunk and being tested for a couple weeks. This is technically not a bug fix, but new functionality, but I'd like to get it into the next release. So, I'm asking permission to merge to release. The change lists are 82083 (for the functionality), 82084 and 82102 (for the tests), and 82103 (for the docs) Thanks! -- Marshall
On 27 December 2012 21:54, Marshall Clow <mclow.lists@gmail.com> wrote:
I have a ticket <https://svn.boost.org/trac/boost/ticket/7652> asking for compile-time checked access to elements of a boost::array.
I have implemented a specialization of boost::get (and for c++11, std::get) that does this, and it's been on the trunk and being tested for a couple weeks.
This is technically not a bug fix, but new functionality, but I'd like to get it into the next release.
So, I'm asking permission to merge to release.
The change lists are 82083 (for the functionality), 82084 and 82102 (for the tests), and 82103 (for the docs)
Some of those revision numbers are wrong. Also, I don't like the idea of adding anything to 'std' at this stage.
On Dec 28, 2012, at 4:50 AM, Daniel James <dnljms@gmail.com> wrote:
On 27 December 2012 21:54, Marshall Clow <mclow.lists@gmail.com> wrote:
I have a ticket <https://svn.boost.org/trac/boost/ticket/7652> asking for compile-time checked access to elements of a boost::array.
I have implemented a specialization of boost::get (and for c++11, std::get) that does this, and it's been on the trunk and being tested for a couple weeks.
This is technically not a bug fix, but new functionality, but I'd like to get it into the next release.
So, I'm asking permission to merge to release.
The change lists are 82083 (for the functionality), 82084 and 82102 (for the tests), and 82103 (for the docs)
Some of those revision numbers are wrong.
Crud. Apparently copy and paste is beyond my mental abilities. 82083 (for the functionality) 82089 and 82102 (for the tests) 82105 (for the docs)
Also, I don't like the idea of adding anything to 'std' at this stage.
I'm not adding stuff to "namespace std", but rather specializing a template function for boost::array that is already defined. But if you think that this is too late/risky to be added to this release, I'm OK with that. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
On 12/28/2012 1:51 PM, Marshall Clow wrote:
On Dec 28, 2012, at 4:50 AM, Daniel James <dnljms@gmail.com> wrote:
On 27 December 2012 21:54, Marshall Clow <mclow.lists@gmail.com> wrote:
I have a ticket <https://svn.boost.org/trac/boost/ticket/7652> asking for compile-time checked access to elements of a boost::array.
I have implemented a specialization of boost::get (and for c++11, std::get) that does this, and it's been on the trunk and being tested for a couple weeks.
This is technically not a bug fix, but new functionality, but I'd like to get it into the next release.
So, I'm asking permission to merge to release.
The change lists are 82083 (for the functionality), 82084 and 82102 (for the tests), and 82103 (for the docs)
Some of those revision numbers are wrong.
Crud. Apparently copy and paste is beyond my mental abilities. 82083 (for the functionality) 82089 and 82102 (for the tests) 82105 (for the docs)
Also, I don't like the idea of adding anything to 'std' at this stage.
I'm not adding stuff to "namespace std", but rather specializing a template function for boost::array that is already defined. But if you think that this is too late/risky to be added to this release, I'm OK with that.
<looks> No, you're not specializing a function template. You're adding an overload. My standardese is rusty, but I don't think that's allowed in namespace std. Anyway, I'm with Daniel. Marshall, can you please hold this change? -- Eric Niebler BoostPro Computing http://www.boostpro.com
No, you're not specializing a function template. You're adding an overload. My standardese is rusty, but I don't think that's allowed in namespace std.
That's my understanding too: overloading std namespace functions is forbidden by the std. And while possibly convenient, why would one expect "get" to be in namespace std when array is in namespace boost? IMO the correct solution (at least as far as the std is concerned) is to call "get" unqualified and let ADL do it's magic. Just my 2c, John.
John Maddock wrote:
No, you're not specializing a function template. You're adding an overload. My standardese is rusty, but I don't think that's allowed in namespace std.
That's my understanding too: overloading std namespace functions is forbidden by the std. And while possibly convenient, why would one expect "get" to be in namespace std when array is in namespace boost?
IMO the correct solution (at least as far as the std is concerned) is to call "get" unqualified and let ADL do it's magic.
As for ADL, function calls with explicit template arguments are different with (ordinary) function calls without them: To make ADL kick in when calling a function call with explicit template arguments, a function template with the **same name** should be visible at the point of the call. See the standard 14.8.1.6. So we need something like this: namespace adl_helper { namespace detail { template <typename T> struct always_false : boost::mpl::bool_<false> {}; } template <typename T> typename boost::enable_if<detail::always_false<T> >::type get(); } int main() { boost::array<int, 3> ar = {{1, 2, 3}}; using adl_helper::get; std::cout << get<1>(ar) << std::endl; } Anyway, std::get overloads done in boost/array.hpp should be removed. Regards, Michel
participants (5)
-
Daniel James -
Eric Niebler -
John Maddock -
Marshall Clow -
Michel Morin