Fix let assigned from construct from array

[Kojoley]

Fixes #58 (comment) problem.

Note: let(_a = construct<T[N]>(...)) is an invalid thing because you cannot return arrays. Some static assert may be placed for this usage.

[Kojoley]

Disclaimer: I do not know if A can be a reference type in this context (actually I tried to remove proto::detail::uncvref and it was fine), but I remember that some old compilers are not fine with A const& if A is already a reference (and it should be done with add_const + add_reference), but at least all tests passes on msvc-10.

[Flast]

Closing and reopening to re-create travis job.

[Kojoley]

I have updated PR with add_const + add_reference for msvc-8.

P.S. Is it normal that I had to add -DBOOST_PHOENIX_NO_VARIADIC_EXPRESSION to wave.cfg to generate the preprocessed files?

[Flast]

IMO, add proxy traits to boost/phoenix/config.hpp and switch its impl with BOOST_WORKAROUND, then use the proxy traits is better way to support buggy compiler.

Anyway, PP-ing is hard for somebody (especially newbie contributor), so defining BOOST_PHOENIX_DONT_USE_PREPROCESSED_FILES while CI is helpful (I'll do).

[Kojoley]

Actually it is not only msvc-8 problem, gcc in c++03 mode complains too https://travis-ci.org/boostorg/phoenix/builds/332629779

Anyway, PP-ing is hard for somebody (especially newbie contributor), so defining BOOST_PHOENIX_DONT_USE_PREPROCESSED_FILES while CI is helpful (I'll do).

I do not see how it will fix problem that currently wave preprocessing goes with the wrong settings and that's why does not generate any output.

[Kojoley]

I suspect the mac builds will take forever to end. You might want to restart them or, better, turn them off.

[Flast]

Sorry for review delaying...

IMO, add proxy traits to boost/phoenix/config.hpp and switch its impl with BOOST_WORKAROUND, then use the proxy traits is better way to support buggy compiler.

Oops, I mistaken you said for it needs two form A0 and add_ref...<A0>::type separately. OK, your patch seems good.

P.S. Is it normal that I had to add -DBOOST_PHOENIX_NO_VARIADIC_EXPRESSION to wave.cfg to generate the preprocessed files?

AFAIK, wave should be executed without c++11 feature flag, i.e. the macro should be defined implicitly.

Anyway, PP-ing is hard for somebody (especially newbie contributor), so defining BOOST_PHOENIX_DONT_USE_PREPROCESSED_FILES while CI is helpful (I'll do).

I think requesting PP-ing inhibits developing cycle (especially newbie developer). Additionally, PP-ed PR is sometimes huge and makes human unreadable (hard to review) one... So, disabling use of PP-ed code while CI, makes contributor don't have to worry about that, is what I meant on that line.