Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Future of the ms-gsl. Versions, Releases, Supported Compilers, New and Removed features #348

Closed
MikeGitb opened this issue Sep 1, 2016 · 2 comments
Assignees
Labels

Comments

@MikeGitb
Copy link
Contributor

MikeGitb commented Sep 1, 2016

Now that the features of the gsl seem to have somewhat stabilized, I'm wondering what the plans for the future development of this library are (I'm mainly talking about Microsoft's gsl in particular - not so much about the gsl-specification).

That encompasses quite a few different but related questions:

  1. First of all, is this supposed to become a reasonable stable, production quality library in its own right or primarily a place to develop new components for the standard library? If the latter is the case, then the following questions are probably not really important.
  2. Are you planning to have some sort of regular or irregular releases (e.g. with a change log etc. and maybe some extended testing and bug fixing period beforehand)
  3. If there are to be releases and version numbers, are you aiming for API/ABI stability (maybe by introducing version name spaces) ?
  4. What are the compilers you want to support in the future (especially how long will older compiler's be supported)?
  5. Are there currently any new features planned for the gsl (this is probably more about the abstract gsl-specification)?
  6. There have been multiple comments that gsl-types will be replaced by standard library types or language features once they are available. Is there any envisioned process for this (e.g. first deprecating them) and is there any concept of what available means?

Now I'm not expecting you to have a answer to all of this (and certainly not a time table or fleshed out policy) but it would be nice to know, how ms is currently envisioning this library's future development.

Most of all: Thank you very much for providing and maintaining this little jewel.

@neilmacintosh
Copy link
Collaborator

neilmacintosh commented Nov 14, 2016

@MikeGitb thanks for the question, and especially, thanks for the kind words.

I'll address your questions in order, and refer by their numbers, to make what will be a long answer hopefully a little easier to follow.

  1. I would assert that this is a stable, production-quality library ;-) We already use GSL within Microsoft in a number of codebases, including Windows, Office, and parts of MSVC. And its aim is very clear: to provide basic, vocabulary types that are useful when writing well-structured, good quality C++. Being a useful, production-quality library does not in any way prevent it from also offering up types that may be useful generally, and hence good candidates for standardization.
  2. I would like to mark releases, something we haven't done up until now. They are unlikely to follow a particularly regular schedule. The most likely cadence I think you will see is that they would align roughly with releases of Visual Studio. In terms of your question about releases in terms of bugfixing and extended testing....I don't plan to have anything like that (and frankly, I don't think we need it). The releases are simply more like checkpoints that help people sync which particular version of the library they are referring to. I'm not planning to get too fancy here - probably just label a particular commit. I'll definitely try to produce a changelog and pop it in a version.md against the label name and commit.
  3. Releases will probably be as simple as marking a particular commit with a descriptive label relating to the event that corresponds to the release. I know there are schemes like semantic versioning out there. I have no plans to do anything like that at the moment. If anyone feels strongly about the need for that sort of thing, I'd love to hear it. Obviously we want to try and keep the API fairly stable, but we prioritize getting things right over keeping things stable for now. ABI stability is just not a concern at this stage as there is no compiled component to the GSL.
  4. In terms of compilers, the "big three" are the main target: MSVC, GCC and Clang. However, I'm always happy to look at PRs that help the library compile elsewhere. For MSVC specifically, I will only keep the GSL compiling for the current and previous releases of MSVC. So as a concrete example: that is the Visual Studio 2013 (latest update) and Visual Studio 2015 (latest update) versions of the compiler for now. Once Visual Studio "15" is release it would become the Visual Studio "15" compiler and Visual Studio 2015 (latest update) compiler.
  5. There is nothing major currently under development for addition to the GSL, though I'm sure some things will appear in the future. In the coming year, I'd like to focus on stabilizing some of the facilities we already have like not_null and multi_span. In terms of things already described (albeit briefly) but not currently implemented, there are two useful types: stack_array and dyn_array. I'd be happy to look at PRs that implement either.
  6. I don't think we'll need a very formal process for switching over to use standardized types when they appear to replace GSL types. It is obviously predicated on the type being included in C++ standard library specification. Once that happens, then as it appears in each standard library implementation that we support, we will conditionally remove our version and switch to a typedef to the standard library type when compiled with that standard library. So at some point after the standard includes the type in question, we would have removed our version of the type for all our major targets.

I hope those answers are useful. If not, or you need more detail to better answer the question, just let me know. Note that my talk at CppCon 2016 also covered some of this material and can be viewed at: https://www.youtube.com/watch?v=_GhNnCuaEjo.

@capsocrates
Copy link

So... about release labels... Will we be getting any of those anytime soon?

I've noticed that the version of the GSL that comes with the Nuget package for VS 2015 is at least a little bit behind the trunk here on github (it still has .h suffixes on all the headers, for instance). It is listed in the package as "Microsoft.Gsl.0.1.2.1" but I have no idea which commit that correlates with here on Github.

I am interested in pulling down a newer version of the GSL than what is in the Nuget package. I would like to have a solid version number to track with, so we can be conscious of exactly which version of the GSL we are using in comparison to what is available. Right now, with no releases or tags of any kind, that seems rather hard to do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants