I'm not sure that SG15 polls on EWG or LEWG things are going to be binding,
particularly. If we've got time to discuss std::compile with the larger
group, I'm not strictly *against* it, but you should be clear that
a) polls won't be binding
b) standardization is a long process - putting a year into it is a great
start, but this is a ship that takes a lot of work to steer.

On Sat, Nov 3, 2018 at 1:43 PM Rene Rivera <grafikrobot_at_[hidden]> wrote:

> On Sat, Nov 3, 2018, 12:29 PM Titus Winters <titus_at_[hidden] 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?
>
> _______________________________________________
> Tooling mailing list
> Tooling_at_[hidden]
> http://www.open-std.org/mailman/listinfo/tooling
>