Variadic fusion::list.

[Flast]

As mentioned in #57, this implementation doesn't support move.
I'll fix it until 1.59 release.

[Flast]

Tested:

• GCC 5.1.1 gnu++98 / gnu++11 / gnu++14
• Clang 3.6.1 gnu++98 / gnu++11 / gnu++14
• MSVC 9.0 / 10.0 / 11.0 / 12.0

[K-ballo]

I think it should be possible to drop this specialization by simply giving list_to_cons<> a call static member function. Have you considered it?

[Flast]

Indeed. I'll drop it.

[Flast]

ping?

[djowel]

Looks good to me. @K-ballo ? It's not perfect, but again, we can incrementally improve this.

[K-ballo]

There's not much for me to do here, a list like this is inherently recursive and thus compile time inefficient. I'm not going to pretend to understand what the value is in having a compile time fixed size heterogeneous list.

[djowel]

Those are very good points. I've been asking myself that same question too, but this one is historical. Arguably, the value is in push_front, but I'm not sure that is relevant anymore, esp. with Fusion's lazy views. I was thinking about deprecating them, but I don't see the point in doing that either. I'd love to hear your and Flast's thoughts.

[K-ballo]

I don't see the point in it, so I'd be fine with taking this PR as-is and deprecating it. I would definitively not include it in a v3 unless someone can think of a reason.

[djowel]

Agreed!

[Flast]

I would definitively not include it in a v3 unless someone can think of a reason.

Agreed too!

.o0(If we go to v3, I wonder we implement sequences other than tuple...

[K-ballo]

.o0(If we go to v3, I wonder we implement sequences other than tuple...

Map and set would be nice, associative only, non-indexable.

[Flast]

Map and set would be nice, associative only, non-indexable.

Ah, yes. I had forgotten those.