On 2/28/2015 6:28 PM, Robert Ramey wrote:
Edward Diener-3 wrote
My reason for supporting the changes for MPL which Stephen Kelly wanted to make is that hackery, no matter how brilliant, for compilers whose support for the C++ standard is poor in some way tends to obfuscate the understanding of how code works. If said compilers are outdated and have been superceded by newer versions which the vast majority of programmers now use, or if the compiler is not supported or marketed anymore, I can understand dropping such workarounds rather than carrying them around forever. Code then become easier to understand and change. One does not have to worry about some old compiler which no one rationally should be using when making additions or changes to a library.
I think we're mixing a couple of things here. Stephen's changes were not just one library he was willing to maintain and take responsibility for, but the whole of boost.
When I spoke of Stephen Kelly's change I meant only those for MPL.
No one could be responsible for that. I think he underestimated the subtle repercussions of changes which which seemed at first glance to be innocuous. In his defense, I think that is very easy to do since a of the hackery is as non-obvious as it is necessary. So let's set Stephen's changes apart from this discussion.
The maintainer has to have the option of doing things in the way he thinks is most expedient. In some cases, that will mean just leaving things as they are, and other cases that will mean throwing out an implementation of some feature and replacing it with a simpler one which is easier to maintain and verify. No one can make an a-priori policy for that.
I was not promoting some a-priori policy, only arguing that the removal of support in MPL for compilers which are ancient, non-conforming, and barely usable in creating modern C++ code is a viable goal in order to make MPL more easily understandable. I agree with you that whoever makes changes to any library is responsible for seeing through those changes. I do not agree with you that this can only be done if a library has a single maintainer in charge of everything. The latter may be a laudatory goal and I do think that the creator of a library if he is still active makes the final call on changes, but the creator(s) of MPL are no longer active on Boost and maintaining the library. Do we then say that because a library no longer has a primary maintainer who created the library that no changes to the library except for bug fixes should ever be made ? That is very unrealistic consider that very few creators of a library are willing to maintain that library perpetually, which is only natural.