Bruno Dutra wrote
2015-04-01 10:13 GMT-03:00, Louis Dionne <
ldionne.2@
>: [...]
Why would you want an MPL replacement when you could have much better?
Well, why would you want much better if you can have much simpler? :)
If you're going to go for C++11/14 anyway, why in heaven would you want to stick to the MPL?
There seems to be a misconception that MPL is utterly outdated and old fashioned, but I beg to differ. I find myself increasingly fond of its design and I particularly like how well it mimics STL. In my opinion, that is precisely one of its greatest strengths.
I don't think that MPL can be seen as "simple". Neither considering its idioms, related mostly to old C++ features. typename ::type, iterator based interface, etc; which make the code far more obfuscated than Meta or Hana. The point of getting the effort to write a new metaprogramming library for Boost is to study how C++11/14, i.e. new features and idioms, can aid when metaprogramming. Getting stuck on old idioms is not a good idea. Want backwards compatibility? Then just install Boost <= 1.57.0. Is that easy. Anyway, I'm agree with Louis that most metaprogramming libraries that have come after C++11 look at tmp in a very different way. The STL-like interface is not a plus point for MPL at all. The STL is not designed for functional programming, and like it or not, TMP is functional. Also comes with exactly the same composability problem the STL has with its iterator based interface. Of course there are workarounds like metafunction classes, but they are just that, workarounds. Iterators make sense with head:tail typelists, but have no place on modern metaprogramming and variadic templates. So, what we are trying to achieve here? Reading the full thread, it's clear that three main bullets raise out: - Simple - Modern - Backwards compatible (Again, just install previous MPL versions) For simple metaprogramming, I think Eric's Meta does the job. Eager, simple, ready for common metaprogramming problems. Modern/reinvent the paradigm? Hana looks nice, throwing away almost all the syntax idiosyncrasies of TMP. I'm trying the same with Turbo, but my goal is to write Haskell-like code (Still on it, Turbo does not currently do that entirely). I think we should accept that TMP is functional, and get the best of the fp world. My long-term goal is to port almost all the Haskell prelude to tmp, in the same sense of FTL but at compile-time. Summing up: MPL style is not the best for modern TMP. If you still keep thinking on a new MPL on the same way of the old one, then the separation between a metafunctions library and a typelists library is the right thing to do. -- View this message in context: http://boost.2283326.n4.nabble.com/MPL-and-MPL-core-tp4673889p4674036.html Sent from the Boost - Dev mailing list archive at Nabble.com.