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.