Andrey Semashev-2 wrote
This sounds very similar to the MPL and MPL.Core separation [1]. I didn't drop workarounds for old compilers (except for one for Borland), but MPL.Core seems to be close to what you list as MPL lite. I think it is quite possible to drop the compatibility cruft from MPL.Core, although I'm not sure how useful that would be.
That's what (part of) the discussion has been about. Since you're doing the work and taking responsibility for it, you get to decide which is the easiest/best way to do it.
Others have stated that newer language features can be used but require a reimplementation. That's probably true, although I'm quite happy with the current MPL.Core interface
I would like to make a clear distinction between interface and implementation. MPL Core/Lite MUST support the the current interface. If convenient and/or useful, the interface could be expanded (but then you'd have to update the documentation and tests). But the implementation could take advantage of modern C++ and wouldn't be required to be compatible with any compiler which doesn't support C++11+. So presumable this would be much easier than the current MPL
(note - not the iterators stuff, which is not part of MPL.Core).
My view is that the concept of type lists (sequences) is orthogonal to metafunctions. I think dividing MPL into two separate libraries would leave us with something easier to understand and maintain and would also reduce dependencies. So instead of having one very large complex library for which we're unable to find a maintainer, we'd have two large complex libraries for which we'd be unable to find maintainers. Is that progress? I think so. Also, I think that we could evolve to this solution without being overly disruptive. -- View this message in context: http://boost.2283326.n4.nabble.com/MPL-lite-or-MPL-2-A-modest-proposal-tp467... Sent from the Boost - Dev mailing list archive at Nabble.com.