Boost C++ Libraries: Ticket #8775: fusion transform and fold not respecting const-ness of the sequence

Eric Niebler — Wed, 03 Jul 2013 21:15:27 GMT

I should note that it actually does compile with msvc, but that's a compiler bug. With gcc and clang, it fails.

anonymous — Fri, 05 Jul 2013 23:49:45 GMT

I'm not sure I understand. Both sequences are non-const above. Also, the call to fold compiles on gcc 4.7.2. Should it not? I'll take a look at the second as soon as I understand some more. What am I missing?

Joel de Guzman — Fri, 05 Jul 2013 23:53:05 GMT

woops, that anonymous is Joel.

Eric Niebler — Sun, 07 Jul 2013 21:44:30 GMT

Right, the sequences are both non-const lvalues, so the elements passed to F and G should also be non-const lvalues. But they're not. They're const lvalues, which means they can't bind to the non-const references.

You should double-check that gcc compiles it successfully. I just tested locally with gcc 4.7.0 and gcc 4.8.1, and compilation fails for both, as well as for clang-trunk.

A quick inspection of the code shows why the transform call fails to compile. There is no overload of transform that takes a non-const sequence. fold is tricker. You would need to dig to find out what's going on there.

Eric Niebler — Sun, 07 Jul 2013 21:48:38 GMT

Oh, you're right about fold. It works on gcc, but fails on clang 3.3.

Joel de Guzman — Sun, 07 Jul 2013 23:44:29 GMT

Originally, Fusion algorithms are pure FP style const non mutating. Why? because they are held by reference and when you concat/build compound algos, my thinking was that it would be weird to have some of the algos mutate the sequence. Slowly, non const versions crept in. People kept on asking. I guess it's time to break free from the design and have all fusion algos take const and non-const sequences.