On 05/07/2013 08:49 p.m., Mateusz Loskot wrote:

...

Sorry for not given feedback on the

...

ADL issue. I haven't given it much though yet, but I'm open to suggestions. No problem. Regrettably, I'm not able to help her, it's fairly new ground to me, still.

If `fusion::begin/end` were defined as variadic function templates (SFINAEd out when used with more than 0 arguments) then they would be a worse match than `std::begin/end`. Given: std::array, 42> foo; begin(foo); it would unambiguously resolve to `std::begin`. At the same time, it means that different Fusion sequences get different "ADL benefits". I am not particularly keen on said non-uniformity. Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com

On 5 July 2013 10:44, Jonathan Wakely wrote:

On 5 July 2013 00:57, Mateusz Loskot wrote:

...

Unfortunately, I have hit t apparently well-known problem. It is the Fusion begin/end ADL issues with C++0x range-based for and such, as discussed and reported here:

http://lists.boost.org/Archives/boost/2010/12/174199.php https://svn.boost.org/trac/boost/ticket/4028

There has been no feedback to the ticket #8241, so I'm not sure what is the Fusion authors' view on std::array adoption. So, a couple of questions:

Do the Fusion authors consider any cure for the ADL issues?

Stop using C++0x compilers and use C++11 compilers? :)

We fixed the standard via Option 5 from http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3257.pdf

Jonathan, Thanks for this paper. It is still unclear to me if/how the option 4/5 might solve the ambiguous calls to begin/end as here: std::array = {{1,2,3}}; boost::fusion::distance(begin(arr), end(arr)) == 3; as the std::array does provide begin/end members. AFAIU, solution that remains is to fully qualify: boost::fusion::distance(boost::fusion::begin(arr), boost::fusion::end(arr)) == 3; So, the following rule kicks: "to call begin() and end() members if they exist, and if not then to make unqualified calls as specified in the current draft." I'm missing something, am I not? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

On 6 July 2013 01:25, Jonathan Wakely wrote:

On 6 July 2013 00:47, Mateusz Loskot wrote:

...

On 5 July 2013 10:44, Jonathan Wakely wrote:

...

On 5 July 2013 00:57, Mateusz Loskot wrote:

...

Unfortunately, I have hit t apparently well-known problem. It is the Fusion begin/end ADL issues with C++0x range-based for and such, as discussed and reported here:

http://lists.boost.org/Archives/boost/2010/12/174199.php https://svn.boost.org/trac/boost/ticket/4028

There has been no feedback to the ticket #8241, so I'm not sure what is the Fusion authors' view on std::array adoption. So, a couple of questions:

Do the Fusion authors consider any cure for the ADL issues?

Stop using C++0x compilers and use C++11 compilers? :)

We fixed the standard via Option 5 from http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3257.pdf

Jonathan,

Thanks for this paper.

It is still unclear to me if/how the option 4/5 might solve the ambiguous calls to begin/end as here:

std::array = {{1,2,3}}; boost::fusion::distance(begin(arr), end(arr)) == 3;

as the std::array does provide begin/end members.

AFAIU, solution that remains is to fully qualify:

boost::fusion::distance(boost::fusion::begin(arr), boost::fusion::end(arr)) == 3;

So, the following rule kicks:

"to call begin() and end() members if they exist, and if not then to make unqualified calls as specified in the current draft."

I'm missing something, am I not?

No, I think I'm missing something: I thought you meant the problem was with the range-based for loop, but it's with other uses of unqualified begin/end.

Yes, I didn't explained the issue in details, just lazily pointed to some referencess.

The standard was changed to *not* use unqualified begin/end when the type has begin/end members, because when there are multiple "greedy" overloads that can be found by ADL there is no simple way to prevent ambiguity.

Right, it makes perfect sense to me.

So I agree that your best option might be to avoid those unqualified calls.

Thanks, that itself is is a very important opinion for me. If Joel agrees, perhaps the std::array adaptor could be added to Fusion with the restrictions documented. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net