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