The Guidelines should specify the GSL

[AndrewPardoe]

Currently Microsoft is providing one implementation that is, to the best of our knowledge, completely portable, ISO-standard C++. It is under MIT license. We plan to improve the documentation and eventually provide a proper specification as part of the guidelines.

[ajneu]

Hi there,

after having seen Stroustrup's talk, I want to try the GSL.
But I cannot. I cannot find developer-friendly details (i.e. tutorial) about it.

A tutorial-based intro to the GSL (common usage examples and use-cases) would be great.

A side-question:
How is it possible that there are already implementations of the GSL?
According to which spec are these people developing? (Alas, not even they provide a tutorial, currently).

I've seen the quickly hacked up FAQ (1, 2), but it's rather vague.
It says "Other implementations by other vendors are encouraged, as are forks of and contributions to that implementation".
How can other implementations be created, if there's no spec and no details?
If you ask me, it looks like mainly aforementioned people and some high-profile friends are driving this forward... which is fine... though it does seem possibly risky to present this stuff at CppCon2015, if your interested "Joe-Excited-C++-Developer", finds it "non-existant", due to a missing good tutorial; the enthusiasm waining a little... Don't underestimate it: if you want something to kick off... give people a tutorial. (This is as true of old K&R, as it can be with modern C++ with STL and GSL-usage: I'm looking forward to it.)

PS: I've just seen this. I hope to see videos of Neil MacIntosh's talks soon!

[neilmacintosh]

Thanks! They should show up on the CppCon channel in the next few weeks. I'm not exactly sure when.

I think it's a very reasonable expectation to have some tutorial documentation for the GSL in addition to the specification.

[danilaml]

GSL really lacks some basic documentation. There isn't even class listing with their purpose and available constructors...

[martinmoene]

Indeed, although clearly a work in progress, a little more help (specification) would be very welcome.

For GSL Lite, I created this not-entirely-up-to-date feature table and this test specification

[BjarneStroustrup]

We have not forgotten. We are still working on a standards-style specification.

[neilmacintosh]

Just as an update while other specifications are outstanding...two of the types defined in the GSL (byte and span) have specifications that are currently working their way through the process of the standards committee aiming towards inclusion in C++20. span is here and byte is here.

[BjarneStroustrup]

Looks good

On 8/9/2016 2:46 PM, Neil MacIntosh wrote:

Just as an update while other specifications are outstanding...two of
the types defined in the GSL (|byte| and |span|) have specifications
that are currently working their way through the process of the
standards committee aiming towards inclusion in C++20. |span| is here
http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0122r3.pdf and
|byte| is here
http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0298r1.pdf.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
#144 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKbTNMiDDE6fKcxtjS-RBmCH-6skmKNRks5qePUfgaJpZM4GEGSv.

[MikeGitb]

You've probably all been busy with getting c++17 out of the door, but I was wondering, if there is any concrete plan to write said specification / documentation / tutorial by now? Or has everyone settled for the current status quo ("The code from microsoft's gsl implementation is the specification)?

By concrete I mean something with a rough time plan, an idea of the format and a person in charge of the process.

[AndrewPardoe]

We are working on this in context of Standardization. We'd prefer to not presuppose the standardization process. Once this is standardized, there's no reason to have a specification in the Guidelines.

Also, we did prepare an intro the GSL that's located in the docs directory of this repo: https://github.com/isocpp/CppCoreGuidelines/blob/master/docs/gsl-intro.md.

Thank you for the suggestion!

[MikeGitb]

We'd prefer to not presuppose the standardization

I'm not sure I understand that reasoning. Afaik not all parts of the gsl are currently even proposed for standardization and afaik there is currently not even a list of types that are supposed to be in a gsl implementation (which is something completely orthogonal to the standardization process).

So that means, until a component gets standardized, other gsl implementations can only follow whatever happens in Microsoft's gsl and once it becomes standardized, the value of the type being in the gsl at all drops rapidly.

[neilmacintosh]

@MikeGitb I think this document does actually list the core parts of the GSL - not_null, span, narrow, Expects\Ensures etc.

I don't believe that other GSL implementations need to follow the Microsoft implementation as their only option. Implementers of a GSL could alternatively implement what is described here, and ask questions and join the discussion if they would like to clarify expectations of those types.

I'm not sure why the value of having a type (e.g. span) in the GSL would drop after standardization. The GSL is a collection of things that support following the Guidelines. If some of those things happen to already be in the standard library (like unique_ptr) then so much the better!

If not everything in the GSL has been proposed for standardization yet, that merely reflects the fact that standardization takes time (and effort), so some prioritization is naturally applied. If we end up with some types that attempted standardization but did not make it, then we'll document them here in more detail.

[hsutter]

Editors call: We are reopening this because it's needed. We do want to rely on the standard for specification (which we can now do with span, the only difference in gsl::span being bounds checking but not the interface), but not all of the GSL is or will be standardized so we should say something more concrete about what is intended. The gsl-intro.md is a good start but we need more -- not detailed standardese specification, but at least what the basic operation of each facility is supposed to be with intended usage examples (some of which exist now but are scattered among guidelines). Microsoft's GSL is one GSL, not the GSL. Also see #1519 (thanks!).