Re: [boost] [mpl] multiset

Subject: Re: [boost] [mpl] multiset
From: Bruno Dutra (brunocodutra_at_[hidden])
Date: 2015-02-19 12:34:00

>
> Regarding compiler compatibility, Hana almost certainly should work
> on GCC 5.0 and Louis nearly has it working on GCC 4.9. I'd imagine
> the compiler which will take the longest is as usual MSVC, but there
> is a reasonable chance that a VS2017 might just provide enough for
> Hana, albeit with many workarounds for the lack of two phase lookup.
>

That is what I mean by dependencies on bleeding edge compilers. Sure, soon
enough these currently experimental compiler versions are going to become
mainstream across most  popular setups, but what about legacy applications
or embedded systems for which, as my very limited experience has taught me,
full standard compliant compilers are rarely provided?

> The "hackish" syntax you mention is partially unavoidable with C++,
> and partially because constexpr was very poorly thought through as a
> language feature in that it is much too hard to get constexpr to be
> exact. This is regrettable, but the ship has sailed now, just as we
> currently overload template syntax with functional compile time
> programming which is definitely hackish. If we were sensible, we
> would deprecate that in favour of something like D's compile time
> programming syntax, but progress on introducing D style syntax has
> been oddly partial (functions mostly).
>

By "hackish" I just ment that decltype-ing constexpr functions to perform
type computations feels rather odd. I'm aware this is mostly a matter of
personal taste, but I'm still skeptical that this idiom would allow type
computations as straightforwardly as traditional template overloading does.
As soon as I have time I will try to implement some fancier logic
predicates using Hana, like unification and SLD resolution, and compare the
verbosity with a traditional approach. Hopefuly it proves me wrong.

Please bear in mind however that I don't mean to diminish Hana by any
means, on the contrary, as I said, I'm very much impressed by its elegance
in accomplishing the task for which it was built. I just advocate that it
fills a very different niche than its predecessor MPL, which, in my opinion
should not be left aside, specially considering its ability to be compiled
by virtually any compiler version targeting any architecture of the last
decade.

I'm just wondering whether the lack of development of MPL in the past years
is just incidental, as developers moved on to new frontiers, or if indeed
if reflects a consensus that MPL is obsolete nowadays, which I find hard to
believe.

*Bruno C. O. Dutra*