Re: [boost] [hana] Lorenzo's Formal review for Hana

On 27 Jun 2015 at 7:27, Louis Dionne wrote:

...

I think you have a good chance of getting it working on VS2017, though with some effort by you to do the port. Not bastardising it, but rather reformulating your code to work around lack of two phase lookup etc.

I'm OK with some effort, but I'm not OK with anything that involves a significant amount of ugly workarounds. The last thing I want is for Hana to fall into the same unmaintainability hell as the MPL is currently in (for good reasons, no doubt).

Working around two phase lookup is mostly ordering your source in the right order such that the same outcome emerges as if two phase lookup were working. Occasionally you can't do such a reorder, in which case you'll need to manually bind lookup from outer namespaces into inner namespaces using the 'using' keyword. It's not difficult, and it's not ugly. Just tedious.

BTW, just as a curiosity, why doesn't MSVC implement proper two-phase lookup?

It processes tokens as it sees them instead of building an AST. If some heuristics spot that an AST is needed (e.g. constexpr), it backtracks and builds a local partial AST just to handle that situation, then it reverts to tokens as it sees them. That obviously means no two phase lookup as you delay all lookup to the point of use. That's my best understanding of the compiler, and I am probably wrong. I'm sure STL will correct me if I am.

...

I hope you're not using lambdas in template template parameters. Chandler tells me MSVC can't mangle some of those, and has to stop dead same as winclang has to.

Do you mean something like the following?

auto lambda = []() { }; tuple xs;

Off the top of my head, I don't think Hana uses this anywere.

I had understood it more to be like: auto l=[](auto){}; auto l2=[l](auto){return l;}; // lambda returns lambda type template struct Foo; Foo<&l2::operator()> foo; But that conversation occurred after many drinks, and my example isn't legal C++, so I am unsure exactly what pattern of mangling can't be mangled under the MSVC ABI. Chandler could tell you straight off.

...

I have found VS2015 quite remarkably better than anything before. In developing my lightweight monad recently which involves plenty of hefty C++ 11 and 14 metaprogramming, I mainly used clang 3.6 on Linux, and then pushed changes to my Jenkins CI without any further local testing.

Out of 100 builds, about four failed with GCC 5.1 due to GCC having incomplete/buggy constexpr support.

Out of 100 builds, less than ten failed on VS2015 due to me using a construct it didn't like. Of course, I was deliberately avoiding Expression SFINAE etc, but the point is that VS2015 has enormously closed the gap with clang and GCC. Over 90% of the time in my case these last few weeks VS2015 will compile any C++ 11 or C++ 14 I wrote and tested only using clang on Linux. That's quite something compared to where we were only a year ago.

I'm glad to hear about this, I really am. I'm eager to see how their support for modern C++ will evolve in the upcoming months/years. The more compilers around for testing, the better.

Yesterday VS2015 errored on some code which compiled flawlessly on clang 3.7 and GCC 5.1. It said the code was non-standard C++, and it would not compile it. VS2015 was right, and both clang and GCC were wrong. I was *astonished*. But there you go: VS2015 was more standards conformant than clang or GCC in that one use case! Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/