On 1/25/13, Fernando Cacciola <fernando.cacciola@gmail.com> wrote:
> On Jan 24, 2013 Beman Dawes <bdawes@acm.org> wrote:
> > Fernando,
>
> I realise now that Andrezej, me and most likely quite a lot
> of the people working on a std proposal don't have a complete
> understanding about how the process actually is.  We only have
> some perception of what's going to happen and that affects the
> contents of the proposal.
>
> So, let me try to get a better grip of how this works.
>
> > While std-proposals and other mailing lists are great for gettin
> > community feedback, the only way to know for sure if a feature
> > is so controversial that it must be pulled is to ask the LEWG,
> > LWG, or SG processing the proposal for a vote at a meeting.
>
> OK.  How do we do that?

Every committee chair has an agenda, ask them to put the paper on
the agenda.  If you cannot attend the meeting, find someone who
will be there to champion it for you.

> Do we just file in the paper in a given state, wait for the
> meeting, get the feedback, proceed to ++ revision, and iterate
> once more?

It's possible to get feedback during a meeting, make a new paper, and
get it reviewed at the same meeting.  If you can do it, and you think
changes will be small, ask to have the paper early on the agenda.

> That's how I've been thinking it is, but then time is against us
> so we tried to get the proposal as best as possible right now.

Very good.

> But maybe there is more dynamic and proactive way to scan the
> WG/SG *before* filing it?

You can get hints, but nothing really official.  The committee has
some constraints, as it operates under international treaty.

> > That is particularly true for something like optional that has
> > a long history of wide-spread use. So you should propose what
> > you think is best for the standard library. Trust yourself. The
> > committee will strike the function if they think it is a problem
> > - that's part of their job.
>
> Ah.. now that's interesting.
>
> Part of my (wrong it seems) impression was that a given paper was
> either entirely accepted or entirely rejected. That you wouldn't
> just remove the parts that are a problem and keep the rest.

Well, typically the committee says "please take that out of the
paper" and then you do and the revised paper is accepted whole.

> If that is the process then it means we can:
>
> Organize the paper as a core proposal and then a sequence of
> optional features. That's quite similar to what we had in mind
> but not quite the same, because I planned to have the optional
> parts filed as separate documents such that they might not even
> be ready for the next meeting.

That's fine, but the final paper should not have the optional parts.

> Other related questions about the process:
>
> 1) Is it OK for a proposal to have something like: we (perhaps
> optionally) propose THIS. If THIS is not accepted then we propose
> THAT instead (and possibly so on with more than one else) ?

Yes.  Sometimes the committee will make up alternatives in the
middle of discussions at the meeting.

> 2) Can a feature be accepted but not in the exact way proposed?
> Putting it another way: is the WG/SG required to either
> accept/reject or can it agree on the idea presented but give it
> its own secification?  For the case of a free functions such as
> get_value_or, it might well happen that the exact way in which
> we come up with it is not sufficiently right, but then the WG/SG
> figures out the right way to do it so the corrected version
> is accepted.

The committee cannot really accept ideas or features, only changes to
the text of the standard.  We vote on a paper that says "apply these
edits to the working draft".  If the committee wants a different
specification, they or you must write a revised paper.

> 3) (I asked this above already) Is there a more direct way to get
> into a conversation with voting committee members in preparation
> for a proposal, other than here?

Typically, discussions happen in mail or at the meetings.

--
Lawrence Crowl

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Fri, Jan 25, 2013 at 5:11 PM, Lawrence Crowl <crowl@googlers.com> wrote:
> On 1/25/13, Fernando Cacciola <fernando.cacciola@gmail.com> wrote:
>> On Jan 24, 2013 Beman Dawes <bdawes@acm.org> wrote:
>> > Fernando,
>>
>> I realise now that Andrezej, me and most likely quite a lot
>> of the people working on a std proposal don't have a complete
>> understanding about how the process actually is.  We only have
>> some perception of what's going to happen and that affects the
>> contents of the proposal.
>>
>> So, let me try to get a better grip of how this works.
>>
>> > While std-proposals and other mailing lists are great for gettin
>> > community feedback, the only way to know for sure if a feature
>> > is so controversial that it must be pulled is to ask the LEWG,
>> > LWG, or SG processing the proposal for a vote at a meeting.
>>
>> OK.  How do we do that?
>
> Every committee chair has an agenda, ask them to put the paper on
> the agenda.  If you cannot attend the meeting, find someone who
> will be there to champion it for you.

The agenda priorities the LWG and LEWG use is roughly:

1) Papers not processed the prior meeting. Hopefully there are few if
any of these.
2) Papers in the pre-meeting mailing for which an author or a champion
is present.
3) Papers in the pre-meeting mailing without an author or champion
present. (The chair asks for volunteers to read the paper, and then
present it.)
4) Late papers not in the pre-meeting mailing.

Priorities get shifted if a presenter is only available at certain
times, or to keep related papers together, or to fit an available time
slot. Most meetings we do get to all papers.

Note that Study Groups run their own show, so may differ in their approach.

>
>> Do we just file in the paper in a given state, wait for the
>> meeting, get the feedback, proceed to ++ revision, and iterate
>> once more?
>
> It's possible to get feedback during a meeting, make a new paper, and
> get it reviewed at the same meeting.  If you can do it, and you think
> changes will be small, ask to have the paper early on the agenda.
>
>> That's how I've been thinking it is, but then time is against us
>> so we tried to get the proposal as best as possible right now.
>
> Very good.
>
>> But maybe there is more dynamic and proactive way to scan the
>> WG/SG *before* filing it?
>
> You can get hints, but nothing really official.  The committee has
> some constraints, as it operates under international treaty.

The WG's and SG's do make tentative decisions between meetings, but as
Lawrence says, the final vote can only happen a meetings.

>
>> > That is particularly true for something like optional that has
>> > a long history of wide-spread use. So you should propose what
>> > you think is best for the standard library. Trust yourself. The
>> > committee will strike the function if they think it is a problem
>> > - that's part of their job.
>>
>> Ah.. now that's interesting.
>>
>> Part of my (wrong it seems) impression was that a given paper was
>> either entirely accepted or entirely rejected. That you wouldn't
>> just remove the parts that are a problem and keep the rest.
>
> Well, typically the committee says "please take that out of the
> paper" and then you do and the revised paper is accepted whole.

Other requests are for name changes, and minor additions (hashing
function, for example) to make the proposal play well with the rest of
the standard. But for a library that has already gone through a peer
review process like Boost's, those kinds of features are usually
already present.

>
>> If that is the process then it means we can:
>>
>> Organize the paper as a core proposal and then a sequence of
>> optional features. That's quite similar to what we had in mind
>> but not quite the same, because I planned to have the optional
>> parts filed as separate documents such that they might not even
>> be ready for the next meeting.
>
> That's fine, but the final paper should not have the optional parts.
>
>> Other related questions about the process:
>>
>> 1) Is it OK for a proposal to have something like: we (perhaps
>> optionally) propose THIS. If THIS is not accepted then we propose
>> THAT instead (and possibly so on with more than one else) ?
>
> Yes.  Sometimes the committee will make up alternatives in the
> middle of discussions at the meeting.
>
>> 2) Can a feature be accepted but not in the exact way proposed?
>> Putting it another way: is the WG/SG required to either
>> accept/reject or can it agree on the idea presented but give it
>> its own secification?  For the case of a free functions such as
>> get_value_or, it might well happen that the exact way in which
>> we come up with it is not sufficiently right, but then the WG/SG
>> figures out the right way to do it so the corrected version
>> is accepted.
>
> The committee cannot really accept ideas or features, only changes to
> the text of the standard.  We vote on a paper that says "apply these
> edits to the working draft".  If the committee wants a different
> specification, they or you must write a revised paper.
>
>> 3) (I asked this above already) Is there a more direct way to get
>> into a conversation with voting committee members in preparation
>> for a proposal, other than here?
>
> Typically, discussions happen in mail or at the meetings.

Thanks, Lawrence!

--Beman

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Fri, Jan 25, 2013 at 7:11 PM, Lawrence Crowl <crowl@googlers.com> wrote:
> On 1/25/13, Fernando Cacciola <fernando.cacciola@gmail.com> wrote:
>> On Jan 24, 2013 Beman Dawes <bdawes@acm.org> wrote:
>> > Fernando,
>>
>> I realise now that Andrezej, me and most likely quite a lot
>> of the people working on a std proposal don't have a complete
>> understanding about how the process actually is.  We only have
>> some perception of what's going to happen and that affects the
>> contents of the proposal.
>>
>> So, let me try to get a better grip of how this works.
>>
>> > While std-proposals and other mailing lists are great for gettin
>> > community feedback, the only way to know for sure if a feature
>> > is so controversial that it must be pulled is to ask the LEWG,
>> > LWG, or SG processing the proposal for a vote at a meeting.
>>
>> OK.  How do we do that?
>
> Every committee chair has an agenda, ask them to put the paper on
> the agenda.  If you cannot attend the meeting, find someone who
> will be there to champion it for you.
>

OK.
I can't attend the meeting myself. And IIUC Andrzej cannot as well.
Last time, Ville Voutilainen, was kind enough to champion it, and I
suppose he might do it again at Bristol (if he's attending)

>> Do we just file in the paper in a given state, wait for the
>> meeting, get the feedback, proceed to ++ revision, and iterate
>> once more?
>
> It's possible to get feedback during a meeting, make a new paper, and
> get it reviewed at the same meeting.  If you can do it, and you think
> changes will be small, ask to have the paper early on the agenda.
>
I see.
In our case that won't be possible.

>> That's how I've been thinking it is, but then time is against us
>> so we tried to get the proposal as best as possible right now.
>
> Very good.
>
>> But maybe there is more dynamic and proactive way to scan the
>> WG/SG *before* filing it?
>
> You can get hints, but nothing really official.  The committee has
> some constraints, as it operates under international treaty.
>
OK

>> > That is particularly true for something like optional that has
>> > a long history of wide-spread use. So you should propose what
>> > you think is best for the standard library. Trust yourself. The
>> > committee will strike the function if they think it is a problem
>> > - that's part of their job.
>>
>> Ah.. now that's interesting.
>>
>> Part of my (wrong it seems) impression was that a given paper was
>> either entirely accepted or entirely rejected. That you wouldn't
>> just remove the parts that are a problem and keep the rest.
>
> Well, typically the committee says "please take that out of the
> paper" and then you do and the revised paper is accepted whole.
>
OK, that is indeed what I thought.

So in the end, an entire paper is either completely accepted or
completely rejected, even if rejection
only means "come back with a new one with the necessary corrections
for the/some next meeting"

We think this particular proposal (std::optional) should really be a
part of the very first "committee outcome" (C++14 or even better, a TS
during 2013). In order to meet that we need to be careful in how we
define the proposal.

1.We submit a proposal for the next meeting

2.Something in it isn't quite right so the proposal is "rejected as
is"  and sent back for review.

3.We revised the proposal, and goto 1.

At 2, perhaps 3 meetings a year (AFAICT),  it's easy to see how, with
3 strikes we're out, or almost :)

Thus, in order to avoid having to loop a new iteration increasing the
risk of missing the chance of having the proposal in the very first TS
or at most C++14, we considered the following strategy:

We separate what we consider essential components of the feature from
those who we could live without (and which we sense can result in a
"no" vote).
Naturally, this is simple enough for certain features, such as
optional<T&> which might very well be presented as a separate proposal
and not be present in C++14. But is difficult at the edges, as is the
case of "get_value_or"

In response to that, Beman mentioned that

"The committee will strike the function if they think it is a problem
- that's part of their job."

I interpret that as: we ourselves will "automatically recreate" the
proposal without that function, then vote in the result, as opposed to
give you the feedback the function needs to be removed, so you need to
file the proposal once again in the feature"

Our goal is to maximize the chances for the paper to be accepted right
there are Bristol. One way to do that is to cut out everything that
might be a problem, and so we did to a certain "comfortable" extent.
Another way would be to, instead of directly cutting out the proposal,
make it such that the committee members have a "reconfiguration
algorithm", so to speak, to reshape it on-the-fly, without going back
to us, so "some version" of it might end up being accepted.

With "reconfiguration algorithm" I mean something like the following example:

A. We propose the following free get_value_or() function....

If A is too problematic, then we propose the member function
..value_or() instead...

The in the meeting, instead of simply rejecting the paper and giving
as the feedback, they present member automatically and without our
intervention choose A or B and vote on the resulting wording.

Is that possible?


Best



--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Fri, Jan 25, 2013 at 3:36 PM, Fernando Cacciola
<fernando.cacciola@gmail.com> wrote:
> On Fri, Jan 25, 2013 at 7:11 PM, Lawrence Crowl <crowl@googlers.com> wrote:
>> On 1/25/13, Fernando Cacciola <fernando.cacciola@gmail.com> wrote:
>>> On Jan 24, 2013 Beman Dawes <bdawes@acm.org> wrote:
>>> > Fernando,
>>>
>>> I realise now that Andrezej, me and most likely quite a lot
>>> of the people working on a std proposal don't have a complete
>>> understanding about how the process actually is.  We only have
>>> some perception of what's going to happen and that affects the
>>> contents of the proposal.
>>>
>>> So, let me try to get a better grip of how this works.
>>>
>>> > While std-proposals and other mailing lists are great for gettin
>>> > community feedback, the only way to know for sure if a feature
>>> > is so controversial that it must be pulled is to ask the LEWG,
>>> > LWG, or SG processing the proposal for a vote at a meeting.
>>>
>>> OK.  How do we do that?
>>
>> Every committee chair has an agenda, ask them to put the paper on
>> the agenda.  If you cannot attend the meeting, find someone who
>> will be there to champion it for you.
>>
>
> OK.
> I can't attend the meeting myself. And IIUC Andrzej cannot as well.
> Last time, Ville Voutilainen, was kind enough to champion it, and I
> suppose he might do it again at Bristol (if he's attending)
>
>>> Do we just file in the paper in a given state, wait for the
>>> meeting, get the feedback, proceed to ++ revision, and iterate
>>> once more?
>>
>> It's possible to get feedback during a meeting, make a new paper, and
>> get it reviewed at the same meeting.  If you can do it, and you think
>> changes will be small, ask to have the paper early on the agenda.
>>
> I see.
> In our case that won't be possible.
>
>>> That's how I've been thinking it is, but then time is against us
>>> so we tried to get the proposal as best as possible right now.
>>
>> Very good.
>>
>>> But maybe there is more dynamic and proactive way to scan the
>>> WG/SG *before* filing it?
>>
>> You can get hints, but nothing really official.  The committee has
>> some constraints, as it operates under international treaty.
>>
> OK
>
>>> > That is particularly true for something like optional that has
>>> > a long history of wide-spread use. So you should propose what
>>> > you think is best for the standard library. Trust yourself. The
>>> > committee will strike the function if they think it is a problem
>>> > - that's part of their job.
>>>
>>> Ah.. now that's interesting.
>>>
>>> Part of my (wrong it seems) impression was that a given paper was
>>> either entirely accepted or entirely rejected. That you wouldn't
>>> just remove the parts that are a problem and keep the rest.
>>
>> Well, typically the committee says "please take that out of the
>> paper" and then you do and the revised paper is accepted whole.
>>
> OK, that is indeed what I thought.
>
> So in the end, an entire paper is either completely accepted or
> completely rejected, even if rejection
> only means "come back with a new one with the necessary corrections
> for the/some next meeting"
>
> We think this particular proposal (std::optional) should really be a
> part of the very first "committee outcome" (C++14 or even better, a TS
> during 2013). In order to meet that we need to be careful in how we
> define the proposal.
>
> 1.We submit a proposal for the next meeting
>
> 2.Something in it isn't quite right so the proposal is "rejected as
> is"  and sent back for review.
>
> 3.We revised the proposal, and goto 1.
>
> At 2, perhaps 3 meetings a year (AFAICT),  it's easy to see how, with
> 3 strikes we're out, or almost :)
>
> Thus, in order to avoid having to loop a new iteration increasing the
> risk of missing the chance of having the proposal in the very first TS
> or at most C++14, we considered the following strategy:
>
> We separate what we consider essential components of the feature from
> those who we could live without (and which we sense can result in a
> "no" vote).
> Naturally, this is simple enough for certain features, such as
> optional<T&> which might very well be presented as a separate proposal
> and not be present in C++14. But is difficult at the edges, as is the
> case of "get_value_or"
>
> In response to that, Beman mentioned that
>
> "The committee will strike the function if they think it is a problem
> - that's part of their job."
>
> I interpret that as: we ourselves will "automatically recreate" the
> proposal without that function, then vote in the result, as opposed to
> give you the feedback the function needs to be removed, so you need to
> file the proposal once again in the feature"
>
> Our goal is to maximize the chances for the paper to be accepted right
> there are Bristol. One way to do that is to cut out everything that
> might be a problem, and so we did to a certain "comfortable" extent.
> Another way would be to, instead of directly cutting out the proposal,
> make it such that the committee members have a "reconfiguration
> algorithm", so to speak, to reshape it on-the-fly, without going back
> to us, so "some version" of it might end up being accepted.
>
> With "reconfiguration algorithm" I mean something like the following example:
>
> A. We propose the following free get_value_or() function....
>
> If A is too problematic, then we propose the member function
> .value_or() instead...
>
> The in the meeting, instead of simply rejecting the paper and giving
> as the feedback, they present member automatically and without our
> intervention choose A or B and vote on the resulting wording.
>
> Is that possible?

As I understand it, it's only possible if someone's available to put
together an updated paper with the reconfiguration you suggest.
Providing wording for multiple alternatives along with instructions
for cutting-and-pasting them together could dramatically lower the bar
for someone who isn't you to do it at the meeting. I'd volunteer, but
I'm likely to be doing the same sort of thing with my string_ref and
range papers. It's also totally fine for you to take comments from,
say, Ville at the meeting, and send us an updated paper during the
week. You don't have to be present to interact.

Jeffrey

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On 26 January 2013 02:14, Jeffrey Yasskin <jyasskin@googlers.com> wrote:
> As I understand it, it's only possible if someone's available to put
> together an updated paper with the reconfiguration you suggest.
> Providing wording for multiple alternatives along with instructions
> for cutting-and-pasting them together could dramatically lower the bar
> for someone who isn't you to do it at the meeting. I'd volunteer, but
> I'm likely to be doing the same sort of thing with my string_ref and
> range papers. It's also totally fine for you to take comments from,
> say, Ville at the meeting, and send us an updated paper during the
> week. You don't have to be present to interact.

Sounds good to me. I can present the proposal, collect feedback and talk to
Andrzej and Fernando over email about any necessary changes. Having
copy-paste-ready wording available will certainly be helpful, as Jeffrey says.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On 26 January 2013 09:14, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
> Sounds good to me. I can present the proposal, collect feedback and talk to
> Andrzej and Fernando over email about any necessary changes. Having
> copy-paste-ready wording available will certainly be helpful, as Jeffrey says.

So, to summarize where we currently stand, I think the potential points of
controversy are

1) to support a get_ptr() or something similar, or to omit it and perhaps add
a generic get_pointer-facility separately
2) to support value_or(), or to omit it and perhaps add a generic
facility separately
3) to support relops between optional<T> and T

Anything else? It's perfectly alright to have a proposal that includes
all of these,
but I just want to be prepared to highlight important issues to the LEWG.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Sat, Jan 26, 2013 at 8:19 AM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 26 January 2013 09:14, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>> Sounds good to me. I can present the proposal, collect feedback and talk to
>> Andrzej and Fernando over email about any necessary changes. Having
>> copy-paste-ready wording available will certainly be helpful, as Jeffrey says.
>
> So, to summarize where we currently stand, I think the potential points of
> controversy are
>
> 1) to support a get_ptr() or something similar, or to omit it and perhaps add
> a generic get_pointer-facility separately
> 2) to support value_or(), or to omit it and perhaps add a generic
> facility separately
> 3) to support relops between optional<T> and T
>
> Anything else? It's perfectly alright to have a proposal that includes
> all of these,
> but I just want to be prepared to highlight important issues to the LEWG.
>
Hi Ville,

Yes, that is exactly right.

We would provide the wording for each of the choices, which are member
get_ptr(), member value_or(), free function get_pointer(), free
function get_value_or(), and the mixed relops, so you just have to
copy-paste to assemble the final wording.

Thank you

--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On 26 January 2013 18:20, Fernando Cacciola <fernando.cacciola@gmail.com> wrote:
>> So, to summarize where we currently stand, I think the potential points of
>> controversy are
>> 1) to support a get_ptr() or something similar, or to omit it and perhaps add
>> a generic get_pointer-facility separately
>> 2) to support value_or(), or to omit it and perhaps add a generic
>> facility separately
>> 3) to support relops between optional<T> and T
>> Anything else? It's perfectly alright to have a proposal that includes
> Yes, that is exactly right.
> We would provide the wording for each of the choices, which are member
> get_ptr(), member value_or(), free function get_pointer(), free
> function get_value_or(), and the mixed relops, so you just have to
> copy-paste to assemble the final wording.

Oh, one thing is missing - optional<T&>. boost::optional supports
those, so I think
you could perhaps consider including them. I suppose the omission of optional
references is partly caused by your concern that a proposal is either accepted
as is or rejected completely, which Lawrence and Beman already explained not
being the case. So I think that's number 4 on the list, and the last review in
Portland already indicated that some LWG members think assignment could
be supported in the same way as with std::reference_wrapper.

Regarding how proposals are handled, I want to point out something: WG21
is _inventive_. It's known for occasionally performing rather heavy morphing
of proposals given to it. ;) That's both good and bad, sometimes...

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.