On Tue, Jan 30, 2018 at 4:09 PM, Niall Douglas via Boost
Firstly, Boost admission requirements are merely that it conforms to the latest published ISO C++ standard. That's currently C++ 17.
I am familiar with the letter of the law.
It's certainly not grounds for a rejection, unless you don't care about the Boost admission requirements.
"Don't care" is emotionally charged language. And also false. I care very much, especially for cases where the Boost admission requirements and review process show a weakness.
a. Outcome provides fundamental vocabulary types. Boost has traditionally been the library collection to provide up and coming C++ features. For example boost::variant is usable in C++11 while std::variant is not
If anything, this is an argument in favour of it being written in C++ 17, even C++ 20.
I disagree. As we have seen in the recent survey, C++11 is overwhelmingly popular. Your advice to consider C++17 is exactly the type of bad decision-making that I am concerned about if Outcome is accepted into Boost. To wit, requiring C++17 would exclude 88% of potential Boost users. Even requiring C++14 excludes two-thirds of all C++ programmers. See: https://www.jetbrains.com/research/devecosystem-2017/cpp/
...But the price is the compiler requirements, which are now high, because compilers just weren't reliably up to it until recently.
Part of the skill of a Boost C++ engineer is to figure out how to make it work on older compilers, without being too taxing on them. We suffer so the users don't have to.
But maybe I can do something for you anyway. After failing to persuade
I think it too small a library to go into Boost alone, so I may just implement it into Outcome as an optional, and usable standalone to C++ 11, extension.
This is again the questionable decision-making that I am concerned about if Outcome is accepted into Boost. I consider adding a substitute for error_code to be outside the scope of the library. Such an addition should be in its own library and get its own review. You are effectively stating that you do not believe your idea has enough merit to survive a review, so you will simply add it to your already-published library. Again, this is within the letter of the law. But is not Best Practices.
I own almost all the copyright. I can license my work under any licence I like, including multiple licences under the Geneva Copyright Convention which is an international law. This is a non issue.
The problem comes when someone else wants to make a contribution. Do they have to agree to both licenses? Or just the one? If someone contributes to the BSL licensed portion in Boost, how will you bring it over to the "real" Outcome?
a.k.a. you don't like me, so no Boost for you. Ok.
This has nothing to do with whether I like you or not. For better or for worse, a Boost library comes with the author attached. How they conduct themselves prior to inclusion is a good indicator of future performance. As you stated yourself in the previous message, you may just add out of scope items to your library once it is accepted. This is precisely the type of decision-making I object to (not the person making it).
You're grinding your axe. I suppose you feel entitled to do so after I publicly chided you on what an opportunity you missed on how you ran the Beast review.
No, that's not correct. I don't feel entitled to anything. My largest objection is by far the incompatibility with C++11 (currently in use by two-thirds of all programmers). Some libraries can get away with requiring higher versions of the language, but this isn't one of them. An error variant is sorely needed by ALL C++ programmers not just the one-third with the luxury of C++14 or higher. Making Outcome work flawlessly in C++11 and on the popular compilers including the one I use would be a significant accomplishment and reflect very positively on the skill and professionalism of the author. Of course, the converse is also true...
But perhaps you should look instead at how Outcome was done: I took the (very) long way round on getting this library into Boost
Yes, and I think this reflects positively on you. I see a lot of effort and work that went into this thing, and you have invested a lot of time and energy responding to everyone on the list and to the users. This is to your credit. I think if Outcome was usable in Beast (C++11 and a reasonably modern version of Visual Studio) I would be leaning towards ACCEPT rather than REJECT. I appreciate your thoughtful reply. Regards