[ub] [isocpp-lib-ext] Busted tooling for string_view

[Nevin Liber]

[adding SG12]

On Mon, Mar 19, 2018 at 1:43 PM, Geoffrey Romer via Lib-Ext <

1. The straw poll results recorded in the Jacksonville wiki (10-4-3-1-3
for constructing string_view from null) are inaccurate.
2. The straw poll results are accurate, but do not constitute consensus.
3. There was consensus in the LEWG meeting room in Jacksonville, but that
decision has somehow been superseded.
4. There is consensus for this change in LEWG, but not in LWG, WG21,
and/or national bodies.

I believe the answer is 4 (1-3 are ridiculous, given that both Nathan and I
were in the room).

There was at least one person who told me ahead of time they would have
voted "no" if they could have been in the room, but because it was
extremely unlikely they could escape their room (and in fact they
couldn't), they didn't have a vote.

This proposal was not seen by SG12, even though it clearly has to do with
defining previous ub.

There was a 93 message thread on this very thing in 2016 <
http://lists.isocpp.org/lib-ext/2016/10/3138.php>, so clearly more than
just "the people in the room reviewing every LEWG paper" have an interest
in this.

Talking with folks afterwards, I know that there are a few people who would
have voted "no" had they been in the room, but I readily admit there is a
non-zero chance that some or all of those folks might have just been
humoring me while I was ranting. :-)

Honestly, I'd rather discuss it instead of going through the dance of
objecting during whatever plenary this gets put forward and voting on it
there.

[Richard Smith]

Post by Nevin Liber
[adding SG12]
On Mon, Mar 19, 2018 at 1:43 PM, Geoffrey Romer via Lib-Ext <

1. The straw poll results recorded in the Jacksonville wiki (10-4-3-1-3
for constructing string_view from null) are inaccurate.
2. The straw poll results are accurate, but do not constitute consensus.
3. There was consensus in the LEWG meeting room in Jacksonville, but that
decision has somehow been superseded.
4. There is consensus for this change in LEWG, but not in LWG, WG21,
and/or national bodies.

I believe the answer is 4 (1-3 are ridiculous, given that both Nathan and
I were in the room).
There was at least one person who told me ahead of time they would have
voted "no" if they could have been in the room, but because it was
extremely unlikely they could escape their room (and in fact they
couldn't), they didn't have a vote.
This proposal was not seen by SG12, even though it clearly has to do with
defining previous ub.

I think we should have a discussion within SG12 as to whether we consider
changes like this to be within our remit. I think some library changes
clearly are (eg, I expect we'd want to be involved in discussions related
to the behavior of less<T*> or vector<const T>), but lots of library
functions have narrow contracts and I don't think we should consider all
changes that widen any of those contracts to necessarily require our input.
This case seems somewhat borderline to me.

There was a 93 message thread on this very thing in 2016 <

Post by Nevin Liber
http://lists.isocpp.org/lib-ext/2016/10/3138.php>, so clearly more than
just "the people in the room reviewing every LEWG paper" have an interest
in this.
Talking with folks afterwards, I know that there are a few people who
would have voted "no" had they been in the room, but I readily admit there
is a non-zero chance that some or all of those folks might have just been
humoring me while I was ranting. :-)

I think you should also consider the possibility that they may have changed
their mind had they been present for the presentation and discussion of the
paper. While the makeup of LEWG during the discussion is unlikely to be
exactly representative of that of the committee as a whole, the people
involved in that discussion are likely the best-informed people on the
topic within the committee.

Honestly, I'd rather discuss it instead of going through the dance of

Post by Nevin Liber
objecting during whatever plenary this gets put forward and voting on it
there.

Procedurally, I consider it to be a valid and useful response of LWG or CWG
to observe that they are very far from having consensus for a particular
proposal or design point thereof within their group, and to accompany the
proposal back to the corresponding evolution group to reconsider in a
combined LWG+LEWG or CWG+EWG session. The combined view of LWG+LEWG or
CWG+EWG is probably closer to representing that of the committee as a whole
than that of LEWG or EWG alone.

Another valid response, particularly if you can bring new information that
was not available in the original discussion, would be to write an
opposition paper for presentation in LEWG, and make sure that all people
with strong opinions on both sides of the debate are invited to the
discussion of that paper.

[Nevin Liber]

I agree. However, I'd rather discuss it in a way that focuses on the
technical merits of the proposal (rather than the meta-level question of
what form and degree of consensus the proposal has), and in a way that
avoids calling the integrity of other committee members into question.

That would be nice, but I have to make my plenary objection as strong as my
technical objection, and IMO degree of consensus is on-topic for the latter.

The wiki notes indicate there was also a (short) Friday discussion on this
paper. Is this true (I wasn't in the room), or is it just a cut/paste
error? The final poll implies it was a separate discussion (far fewer
votes), and I would have made it my business to be in the room for it had I
known the discussion would continue.

[Nevin Liber]

Post by Nevin Liber
That would be nice, but I have to make my plenary objection as strong as
my technical objection, and IMO degree of consensus is on-topic for the
latter.

s/latter/former