On Sat, Nov 3, 2018, 12:29 PM Titus Winters <titus@google.com wrote:
Since the SG15 group has already seen and discussed that, I'm not sure how much value there is in talking about it with the same people.

It has the usual value that discussing proposals in F2F or tele-con official SG meetings have.. hearing from a slightly different audience, feedback on the *actual revision* instead of a draft, but most importantly voting on poll questions.

It'll have to be seen by a standarization group (LEWGI, for instance) in order to make progress toward actually standarizing. 

Right. But it would be irresponsible to have them look at it if SG15 doesn't think this is a direction we should take. After all, isn't this the point of the SGs: to study, research, and filter proposals?

So, probably mention it but I assume we won't spend a lot of SG15 time on it.

Okay I can do that. But that seems unfair to me. I'm expending a lot of resources just to be able to attend the one day SG15 is meeting because SG15 doesn't meet "out-of-band". And attending to present the paper I spent a week writing instead of the one I worked on for more than a year is discouraging. How do we expect to "In 10 years, the committee should be able to..." if we are meeting so infrequently? Are you prepared to chair regular non-f2f meetings (as SG14 does for example) to compensate? Should I be considering alternate avenues to move things along?

To help put things in context I had prepared these 7 questions (after I submitted the R0 version) to get direction from the committee:

1. For option short and long names, should we use existing practice?
2. For option short and long names, should we abandon existing practice and prefer more intuitive names?
3. Should we add a constexpr overload that compiles in-place?
4. Should we add an extern "C" function that is callable externally?
5. Is the International Standard a viable method to standardize core compiler options?
6. Are standing documents a viable method to standardize core compiler options?
7. Are standing documents a viable method to standardize experimental and vendor compiler options?