Subject: [SG10] Name stability and our process
From: Nelson, Clark (clark.nelson_at_[hidden])
Date: 2013-05-04 22:52:10
> > 2) At what point will we consider these names stable enough for
> > compiler vendors to start providing them? Are we OK with compilers
> > starting to define these today? (FWIW, I think this is fine.)
> This raises a good point: Versioning of the list. Currently, it's
> just Clark's ideas, not coordinated with anyone. I'd like to see
> at least an N-numbered paper and possibly a "letter ballot"
> equivalent [i.e. a table of interested people with yes/no/abstain]
> recorded on some wiki page, or a teleconference, to "ok" a given
> version of the list. Remember that we can't change the names
> going forward.
I think this topic deserves a separate thread. We are blazing completely new ground.
The usual product of an ISO effort is a standard or other document, which is produced by a well-understood process, and approved by a wide variety of national bodies, each of which has had a chance to review the document. The process and the approval give the document its credibility, and make people believe that it's good enough to follow.
But we're not planning to push a document through that process, nor to get that approval. So how will our recommendations gain the credibility that will motivate people follow them?
Personally, I believe our best chance of that will be to demonstrate that PL22.16 and WG21, the ultimate technical experts on C++ if you will, believe that they are worth following. In other words, we need to get an approval vote on our recommendations recorded in the minutes of a meeting. For the purpose of getting such a vote, the most straightforward thing would be to have our recommendations in an N-numbered document.
I mentioned this idea in the meeting a couple of weeks ago. No one disagreed with me at the time, but we didn't actually stop and ask whether there was consensus on that point. Worse yet, the discussion also included talk of maintaining our recommendations as a live document on a wiki. And it's also not perfectly clear whether that idea achieved consensus, nor how to reconcile the two ideas if a majority actually like both of them. For example, if the wiki is updated frequently, exactly how might we keep track of exactly which parts were covered by a WG21 approval vote?
One of the interesting things about Jens' comments above is that, when he talks about something like a letter ballot, I can't be certain whether he's talking about polling SG10 or PL22.16/WG21. Both might be reasonable, at different steps of the process.
But I will go ahead and say this: I was originally at least hoping to publish my table in a WG21 N-document in the post-meeting mailing. I didn't because I ran out of time, and because it seemed like it might be better to wait for that step until we had demonstrated consensus among SG10 members, at least.
In any event, I think we have two posts to pass: first, consensus among SG10 members. Second, consensus within PL22.16/WG21. I would suggest that implementers should wait until at least the first one to commit to specific macro names.
But if enough implementers go ahead with the names as soon as SG10 agrees on them, then I suppose WG21's approval will be moot: it will be a fait accompli.
SG10 list run by herb.sutter at gmail.com