On 24 September 2015 at 11:22, David Sankel wrote:

I floated the idea of including GSL in Boost as a distribution mechanism to Bjarne and he said he doesn't have any objection to the idea in principle, although he is hesitant to having to go through an extensive review process where some of these basic structures would change.

What do you all think? Would it be appropriate and/or desirable to have a Boost.GSL library?

I'm leaning against it. We aren't peer reviewing the library, and have no ability to reject things we don't like. IMO, it's already bad enough to be under isocpp, as many people mistakenly believe this will be C++ Committee approved, even though in reality this week is the first the committee has heard of it and the committee has never voted on it. And then comes the obvious question: if we are hosting the GDL, then Boost is tacitly approving those new coding guidelines, so shouldn't all new submissions to Boost follow those guidelines? -- Nevin ":-)" Liber mailto:nevin@eviloverlord.com (847) 691-1404

On Thu, Sep 24, 2015 at 12:22 PM, David Sankel wrote:

As you may or may not know, Bjarne Stroustrup, Herb Sutter, and others have announced a new set of C++ guidelines[1] and an accompanying library[2] that supports them. For many folks, it would be difficult to incorporate a new library into their organizations, but there is a strong desire to make use of the guidelines.

I floated the idea of including GSL in Boost as a distribution mechanism to Bjarne and he said he doesn't have any objection to the idea in principle, although he is hesitant to having to go through an extensive review process where some of these basic structures would change.

What do you all think? Would it be appropriate and/or desirable to have a Boost.GSL library?

The full talk is available at https://www.youtube.com/watch?v=1OEu9C51K2A Herb Sutter's take the next day is also essential to understanding the whole picture. See https://www.youtube.com/watch?v=hEx5DNLWGgA Because the purpose of the GSL is to use the C++ type system to annotate source code in a portable way so that a static analyzer can detect otherwise undetectable errors, the GSL is closely tied to the static analyzer, the best home for the library is under the direct control of the team (led by Neil MacIntosh) who are developing the static analyzer. And with the library up on GitHub there isn't really a distribution problem. Incidentally, the VC++ version of the analyzer is due to ship next month, with the clang version to follow relatively soon after that. I haven't heard when the GCC version might ship yet. Incidentally, it was also announced that the VC++ implementation of a proposed C++ Modules TS system will ship with Visual Studio 2015 update 1. No official announcement of when that will ship, but the guessing is they are aiming for sometime in October. --Beman

On 24.09.2015 19:22, David Sankel wrote:

As you may or may not know, Bjarne Stroustrup, Herb Sutter, and others have announced a new set of C++ guidelines[1] and an accompanying library[2] that supports them. For many folks, it would be difficult to incorporate a new library into their organizations, but there is a strong desire to make use of the guidelines.

I floated the idea of including GSL in Boost as a distribution mechanism to Bjarne and he said he doesn't have any objection to the idea in principle, although he is hesitant to having to go through an extensive review process where some of these basic structures would change.

What do you all think? Would it be appropriate and/or desirable to have a Boost.GSL library?

I didn't take a deep look into it but I'd like a clarification as to what is being proposed. I can see there is a library of different components, some of which are probably useful (again, I didn't take a detailed look). Most of it looks like it could be proposed as an extension of Boost.Utility, but it could be separated into one or multiple libraries. In any case, I think this submission could be interesting. A review is absolutely necessary, and I'm actually surprised that Bjarne is hesitant to pursue a review - after all, the point of the review is to make the library better. I take it he simply doesn't have time for that (I hope that's the actual reason, not misbelief in the community). Please note that for the review to happen, the library components will have to be documented and tested. The second part is the guidelines (i.e. the document with the coding rules). I think Boost is not the right place for it, and neither isocpp is. This is a too controversial document, whoever is writing it, so it should probably be in a book or something that clearly states that this is the author's personal opinion. Personally I disagree with some of the guidelines, so I would probably reject it during the review anyway.

The Guidelines document at https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md has added a FAQ: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md... It addresses several of the issues and questions that had come up in this thread, so is worth a quick read if you care about the C++ Guidelines initiative. --Beman

On 25/09/2015 04:22, David Sankel wrote:

What do you all think? Would it be appropriate and/or desirable to have a Boost.GSL library?

I think the operative questions here are: 1. Are Boost libraries likely to want to depend on GSL (eg. using owner<T> and other new types / fake keywords)? 2. If #1 occurs, which of the following would Boost prefer to do? a) Include the "real" GSL as part of Boost. b) Introduce an adapter library that provides macros/types that let Boost libraries conditionally compile with "real" GSL provided externally or without any GSL. I think previous responses have already reached consensus that there is little value in including GSL in Boost without any such dependencies. I doubt these questions can be answered until GSL and its static analyser have gained more maturity and library developers have had a chance to try it out and see if it provides benefit to maintaining their own libraries, or are ok with potential API breakage for library consumers. (In theory it shouldn't take them too long, as this seems to be mainly an effort to provide some of Microsoft's SAL [1] in a more cross-platform way, so they've had some practice.) [1] https://msdn.microsoft.com/en-us/library/ms182032.aspx