Re: [boost] [mpl] multiset

Subject: Re: [boost] [mpl] multiset
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-02-19 15:28:54

On 2/19/2015 12:34 PM, Bruno Dutra wrote:
>>
>> 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.

I believe it reflects the fact that the two developers mostly 
responsible for creating MPL are not very active in Boost anymore.

A while back Stephen Kelly specified changes to MPL to get rid of  hacks 
for old compilers that nobody should be using anymore, and which would 
simplify the MPL code a bit so that new development could more easily be 
done with the code. But these changes were never made and the opinion 
was voiced that Hana would supercede MPL so why make any changes to MPL 
itself. I am with you in believing that until a new  metaprogramming 
idiom becomes more popular, such as Hana or maybe Eric's blog 
contribution, it is worthwhile looking at possible improvements in MPL 
and it is certainly worthwhile fixing any bug reports which may have 
been made against MPL.

I can understand the nervousness by which others view any changes to 
MPL, since it is so heavily used by other libraries and such a core 
library, but I do not understand the point of view that MPL should 
remain as frozen as possible so as not to cause problems with other 
libraries which use it.