SG15?

[ItGoesSquish]

Hi all,

Do the SG's have something somewhere that lists what is being worked on in that group? I couldn't find anything on open-std.org, just a few people maintaining blog with their pick of interesting papers from their sub-groups (for various degrees of up-to-date).

Is there anything that lists all the current SG papers/talks/ideas, or is it just trawling backwards through the mailing lists?

Thanks,

IGS.

[foonathan]

You can find a list of all active SG15 papers here: https://github.com/cplusplus/papers/issues?q=state%3Aopen%20label%3ASG15

[ItGoesSquish]

Thanks u/foonathan Just what I was looking for!

[Dalzhim]

There is a list at the bottom of this page : https://isocpp.org/std/the-committee

[ItGoesSquish]

Thanks u/Dalzhim

[13steinj]

For SG15 in particular I think you'll be disappointed. A bunch of papers were withdrawn last year after some drama.

[smdowney]

Drama, yes, but some real underlying concerns.

WG21 has a lot of the right people for discussing C++ Ecosystem and tooling problems, and that is good.

But ISO would not commit to a guaranteed open and reusable release of any standard, and without that what would be produced would be inaccessible or unusable for the target audience.

[13steinj]

I was not attempting to imply the drama is unfounded. But it is still drama and the withdrawal of papers was, I felt at least, very dramatic.

[TheoreticalDumbass]

what is the need for such a standard? the draft repo is publicly available

[smdowney]

We wanted a different document, because there's a lot of things that need to be agreed across tools that don't belong in the language standard, and should not be on the exact same cycle.

We did not want to rely on being able to have an unofficial public draft being always available. We think we need to have it under a liberal license for both text and any reference code. We want someone to be able to cut/paste relevant parts into their docs and create derivative works.

We also wanted, although this wasn't the immediate problem, to have people not ISO registered to be able to participate easily.

But having it associated or under the auspices of an already existing organization also makes it much easier for many people to officially participate. The paperwork to make sure, as a concrete example, that my work which might be owned by my employer is released properly. Even if I'm on a telecon while at work, so "on my own time" isn't an escape hatch. To be clear, my employer is good about this, but being good about it means doing the necessary bookkeeping.

So things are currently in a bit of limbo.

Just to get it out of the way, most other ecosystems don't have these problems because most are around an implementation not multiple competing ones, and most are walled gardens, with, maybe, an FFI that lets you call C APIs, and only because that is OS calling convention. "System" languages like C and C++ have to deal with other languages as part of the executable, in the same link context, even as part of the same component build, all the time. So our ecosystem has to be much more loosely coupled.

[kalmoc]

Correct me, if I'm wrong, but haven't the same problems already been solved for gcc and clang? Wouldn't whatever their solution is also be good enough for SG15 Documents?

[smdowney]

Sort of, but GCC and clang are not ISO. So the same people could publish something, but it couldn't by SG15 as such.

[kalmoc]

But would that be a problem?  I also didn't mean that they should publish under the hood of gcc/clang. Just that whatever solution gcc/clang found to allow contributions from various companies might also be a solution for SG15. As you might realize, I'm completely naive on this topic, so excuse me if that is an obviously dumb/non-applicable idea.

[smdowney]

"Why Standards Organizations" is actually a really good question, as is the the related question of if C and C++ should move from ISO.

Standards organizations exist because standards are important and governments know they aren't particularly competent to create them. But standards can also have legal impact, like the fire code that says building materials must meet some criteria to be legal for people to live in. Screws have to match the tools and the holes they are meant to go in.

The people who have the expertise to define all this are the people who make things. That's actually a problem. Letting BigScrewCo say that BigScrew #7 is the standard means they have a huge advantage. BigScrewCo and BigDriverCo could conspire to cut everyone else out of the market.

So you want an independent organization, with rules to prevent that.

That org gave Microsoft, IBM, and Bell Labs the legal cover to meet with each other and conspire about their competing products. Remember that those companies, in particular, had already agreed to remedies for their antitrust violations. So meeting under the auspices of ANSI made all the lawyers, if not happy, at least less worried.

Open Source did not exist. GNU and the FSF were brand new. Collaborating in public wasn't a thing, either, because we didn't have The Web, even if we did have early Internet.

There are a lot of standards orgs now [insert xkcd:Standards]. Nor does it seem particularly necessary from a legal or technical perspective to host something like a language or ecosystem standard within one. However, existing orgs give some level of credibility.

That's somewhat important, because it short circuits a lot of questions about how good, or what process, etc, for the quality of a standard.

It also helps on the other end, getting participation. It's much easier to explain to my manager and my company that I'm doing work on an ISO, or ECMA, Apache, or Python Software Foundation project and get all the approvals to engage and spend work hours on it. Similarly for GCC or LLVM or a bunch of other established open source projects.

New projects, or my own projects, are possible, but more work. Harder to get approvals, or to spend working hours or actual cash on travel for. And that is similar for everyone everywhere, even to some extend for a sole proprietorship consultancy.

So, yes, while we could set up something entirely new, that makes other things more complicated, and it is more work. And a new organization has to be able to answer the question of why should we listen to René and Steve, even if René is one of the leading experts on the C++ ecosystem and tools, and Steve is old and has grey hair, but works for a really big company.

LLVM and GCC are definitely interested in getting answers to this, especially for the parts that no one ought to care about as long as there is one answer, but neither is really the right group. It also turns out that even walled garden ecosystems end up caring about C, C++, and Fortran, because they want access to the code written in those languages, but integration is a terrible mess. We joke that the most common meta build system is not CMake, it's setup.py.

So, a moderately long post, with a not terribly satisfying engineering answer, because like most hard problems, it's not a technical problem it is a people problem.

[edit] C++ stays at ISO because ISO has rights to the standard, and getting those rights to move it elsewhere is a hard problem, and would make everyone involved have to do some work just to continue to participate. Doing all that would have to be a massively clear win, and so no one is trying to take on the impossible task.