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

Subject: Re: [boost] [hana] Lorenzo's Formal review for Hana
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-06-27 15:31:32

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<decltype(lambda)> 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<template<class> R (C::*)(Args..), class R, class C, class... 
Args> 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/