Refining Concepts: Separate checking, part 1, relaxing constraints

[Tom Honermann]

My very slow progress analyzing the technical concerns described in the original "Why Concepts didn't make C++17" post continues...

Blog: http://honermann.net/blog/2016/09/18/refining-concepts-separate-checking-part-1-relaxing-constraints/
Twitter: https://twitter.com/tahonermann/status/777434002961600512
Reddit: https://www.reddit.com/r/cpp/comments/53bh20/refining_concepts_separate_checking_part_1/

Tom.

[Bjarne Stroustrup]

So now we are to have our technical discussions on twitter. Seriously?

--
You received this message because you are subscribed to the Google Groups "SG8 - Concepts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to concepts+u...@isocpp.org.
To post to this group, send email to conc...@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/concepts/.

[Ville Voutilainen]

On 18 September 2016 at 16:10, Bjarne Stroustrup <bja...@stroustrup.com> wrote:
> So now we are to have our technical discussions on twitter. Seriously?

I don't think we are. I welcome people exploring concepts, but
nevertheless, what we need are proposals;
Evolution cannot discuss blog posts, however old-fashioned that may be.

[Tom Honermann]

On 09/18/2016 09:30 AM, Ville Voutilainen wrote:

On 18 September 2016 at 16:10, Bjarne Stroustrup <bja...@stroustrup.com> wrote:

So now we are to have our technical discussions on twitter. Seriously?

I do not expect discussion of these posts made on Twitter, Reddit, or anywhere else to be any kind of substitute for the discussion that happens within the committee.

Perhaps it would be helpful if I explained my motivation for writing these posts.

As was clearly shown in Jacksonville, the committee did not have consensus on the current design of the Concepts TS.  If we were to take those polls again today, I expect that we'd see little change.  My hope is that, by providing an analysis of the issues raised, I might help to dispel mismatched expectations, clarify the concerns, center the discussion, identify solutions, and ultimately improve consensus.

So, why (old-fashioned) blog posts instead of papers?  When getting up to speed on Concepts, I found it challenging to identify the rationale for many of the choices made in the C++0x Concepts and Concepts TS designs (I'm still quite new to the committee).  There are many Concepts related papers (I have 126 bookmarked, many of which are revisions of each other).  It takes considerable time and effort to identify and appreciate the design choices and trade offs that have been made, and committee discussion is not open to the public (for good reasons).  By writing these posts, I hope to clearly present the issues raised with simple examples and analysis of at least one possible solution and to provide a public reference for them.  Consider the question Herb Sutter posed [1] earlier this year.  He asked, "For reference, could someone please link to a reasonably current concise summary of definition checking and the debug/data collection issues? Some examples would be a good refresher here.".  There were no responses.  I've looked for such a summary and for examples and been unable to find any.  I've now provided one.

Additionally, I view these posts as solicitation for feedback on the solutions I'm discussing in the hopes that they reveal gaps or errors in my analysis, likelihood of community acceptance, better solutions, etc...  I (or others) can then use that feedback to write formal proposals that already show some signs of likely consensus.  The std-proposals mailing list exists to fulfill this purpose as well, but Twitter, Reddit, et al. have much greater reach.  I'll note that proposal P0324 [2] was motivated by one of my posts, and I see that as a sign of encouragement.

I don't think we are. I welcome people exploring concepts, but
nevertheless, what we need are proposals;
Evolution cannot discuss blog posts, however old-fashioned that may be.

And just to be clear, I don't expect Evolution to do so.  I hope to eventually submit real proposals, though time has been hard to come by.

Tom.

[1]: https://groups.google.com/a/isocpp.org/d/msg/concepts/CX3aUunonaI/ZHE2DzMmFgAJ
[2]: http://wg21.link/p0324

[Andrew Sutton]

As was clearly shown in Jacksonville, the committee did not have consensus on the current design of the Concepts TS. 

I don't think that was clearly shown at all. Most of the committee wanted more bake time (including practical experience) for the design embodied in the TS.

FWIW, the feature proposed in your most recent blog post has been known, considered, and discussed privately for at least 5 years. At the time Concepts Lite was proposed, C++ didn't have a mechanism for dealing with this in an appropriate way (the static-if proposals of 2011 would have made definition checking impossible, among other things). 

Concepts Lite was designed very carefully. If you're really interested in that design, you might try asking here instead of trying to extrapolate from proposals. 

--

Andrew Sutton

[Ville Voutilainen]

On 18 September 2016 at 23:40, Tom Honermann <t...@honermann.net> wrote:
> As was clearly shown in Jacksonville, the committee did not have consensus
> on the current design of the Concepts TS. If we were to take those polls
> again today, I expect that we'd see little change. My hope is that, by
> providing an analysis of the issues raised, I might help to dispel
> mismatched expectations, clarify the concerns, center the discussion,
> identify solutions, and ultimately improve consensus.

I have unsatisfactory evidence of the non-consensus being an outcome
of the design not
being good enough, or that the outcome of the vote would be more or
less the same today.
Some vague recollections:

1) "The TS hasn't been out for 'long enough'." I certainly don't know
what constitutes 'long enough'
for various audiences, but it certainly has been out longer. :)
2) "Concepts haven't shipped in a compiler release." Well, now they have.
3) "The error messages of constraint violations in the only
implementation don't explain what part
of a constraint was violated." Well, now they do.

To be fair, we still don't have more than one implementation, and I
haven't heard any implementation
progress reports. We also don't have much in the area of new user
experience reports that I know of.

We have some papers suggesting design changes, which at least allows
us to discuss them.

[Ville Voutilainen]

On 19 September 2016 at 02:03, Andrew Sutton <andrew....@gmail.com> wrote:
> FWIW, the feature proposed in your most recent blog post has been known,
> considered, and discussed privately for at least 5 years. At the time

Perhaps that discussion and its related considerations and examples
need to be made more public.
I don't think it serves anyone's purposes to have the designers of
Concepts plus me to understand the
various considerations involved and their consequences, but the rest
of the committee having
at most a vague understanding of it. The worst possible outcome we
could have is people with
varying degrees of education on the subject matter of definition
checking continuing to insist
on having it, and then the committee failing to ship Concepts in C++20
in case we don't provide
definition checking. That would be an unmitigable disaster.

[Andrew Sutton]

Perhaps that discussion and its related considerations and examples
need to be made more public.
I don't think it serves anyone's purposes to have the designers of
Concepts plus me to understand the
various considerations involved and their consequences, but the rest
of the committee having
at most a vague understanding of it.

I think we discussed the idea of "local constraints" around the time the static-if papers landed. Static if aside, we ended up rejecting the idea of local constraints, favoring overloading, because if conditions limit you to sequences of true/false conditions, whereas subsumption gives you a ordering. 

But this issue only matters if you're requiring concepts to include definition checking, although it is *way* better that late_check. 

The worst possible outcome we
could have is people with
varying degrees of education on the subject matter of definition
checking continuing to insist
on having it, and then the committee failing to ship Concepts in C++20
in case we don't provide
definition checking. That would be an unmitigable disaster.

I wonder if that ship hasn't already sailed. People that want definition checking seem to be totally unaware of its costs.

--

Andrew Sutton

[Ville Voutilainen]

On 19 September 2016 at 03:41, Andrew Sutton <andrew....@gmail.com> wrote:
>> The worst possible outcome we
>> could have is people with
>> varying degrees of education on the subject matter of definition
>> checking continuing to insist
>> on having it, and then the committee failing to ship Concepts in C++20
>> in case we don't provide
>> definition checking. That would be an unmitigable disaster.
>
>
> I wonder if that ship hasn't already sailed. People that want definition
> checking seem to be totally unaware of its costs.

Some of those people have votes in the committee. I think it unwise to
let them loose
as uneducated as they currently are.

[Tom Honermann]

On 09/18/2016 07:15 PM, Ville Voutilainen wrote:
> Perhaps that discussion and its related considerations and examples
> need to be made more public.
> I don't think it serves anyone's purposes to have the designers of
> Concepts plus me to understand the
> various considerations involved and their consequences, but the rest
> of the committee having
> at most a vague understanding of it. The worst possible outcome we
> could have is people with
> varying degrees of education on the subject matter of definition
> checking continuing to insist
> on having it, and then the committee failing to ship Concepts in C++20
> in case we don't provide
> definition checking. That would be an unmitigable disaster

This is exactly what is motivating my posts. If we never get definition
checking, I'll live. My concern is consensus. I've spoken with a few
people about their concerns and followed email threads like [1]. The
impression I get is that some committee members are unconvinced that a
palatable solution for definition checking can be delivered on top of
the Concepts TS despite assertions having been made that definition
checking is possible and can be added later. I think some of these
folks would feel more at ease if they had an analysis of the options and
trade offs to be considered; they could then decide for themselves
whether a reasonable solution can be expected. I haven't been able to
find any existing analyses, so, that's what I'm trying to provide with
these posts. The goal is to document the concerns succinctly and
publicly, offer a fair analysis of some possible solutions, and hope
that doing so quells some fears.

Tom.

[1]:
https://groups.google.com/a/isocpp.org/forum/#!msg/concepts/CX3aUunonaI/D6-jtlkfFgAJ

[Tom Honermann]

And as I've found, it is rather difficult and time consuming to get
educated at present.

Tom.

[Tom Honermann]

On 09/18/2016 07:03 PM, Andrew Sutton wrote:

As was clearly shown in Jacksonville, the committee did not have consensus on the current design of the Concepts TS. 

I don't think that was clearly shown at all. Most of the committee wanted more bake time (including practical experience) for the design embodied in the TS.

I agree that timing was the predominant concern.

FWIW, the feature proposed in your most recent blog post has been known, considered, and discussed privately for at least 5 years. At the time Concepts Lite was proposed, C++ didn't have a mechanism for dealing with this in an appropriate way (the static-if proposals of 2011 would have made definition checking impossible, among other things).

That doesn't surprise me.  I'm not expecting to actually come up with any new ideas that haven't already been discussed given the long history of the Concept designs.

Concepts Lite was designed very carefully. If you're really interested in that design, you might try asking here instead of trying to extrapolate from proposals.

It's clear that it was designed carefully.  And, yes, I would probably benefit from asking more questions here.  I have a strong tendency to research on my own.

Tom.

[Tom Honermann]

On 09/18/2016 07:07 PM, Ville Voutilainen wrote:
> On 18 September 2016 at 23:40, Tom Honermann <t...@honermann.net> wrote:
>> As was clearly shown in Jacksonville, the committee did not have consensus
>> on the current design of the Concepts TS. If we were to take those polls
>> again today, I expect that we'd see little change. My hope is that, by
>> providing an analysis of the issues raised, I might help to dispel
>> mismatched expectations, clarify the concerns, center the discussion,
>> identify solutions, and ultimately improve consensus.
> I have unsatisfactory evidence of the non-consensus being an outcome
> of the design not
> being good enough, or that the outcome of the vote would be more or
> less the same today.

And I have no evidence to offer either.

> Some vague recollections:
>
> 1) "The TS hasn't been out for 'long enough'." I certainly don't know
> what constitutes 'long enough'
> for various audiences, but it certainly has been out longer. :)
> 2) "Concepts haven't shipped in a compiler release." Well, now they have.
> 3) "The error messages of constraint violations in the only
> implementation don't explain what part
> of a constraint was violated." Well, now they do.

All true. And 2 and 3 were very welcome progress. Performance has also
improved substantially.

> To be fair, we still don't have more than one implementation, and I
> haven't heard any implementation
> progress reports. We also don't have much in the area of new user
> experience reports that I know of.
>
> We have some papers suggesting design changes, which at least allows
> us to discuss them.

And I look forward to those discussions :)

Tom.

[Andrzej Krzemieński]

Thank you for doing this. I found these blog posts very informative. I know that this is nothing new for people who participate in these discussions in the Committee. But for the people form the outside, like me, this is really helpful.

Regards,
&rzej;

[Bjarne Stroustrup]

Maybe this tutorial material from Andrew Sutton will be of help:

https://accu.org/index.php/journals/2157

https://accu.org/index.php/journals/2198

https://accu.org/index.php/journals/2160

And this from Eric Niebler:

https://ericniebler.github.io/range-v3/

Note also:

Iterator facade: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0186r0.html

an academic paper exploring the ideas in the contrext of computer algebra: http://www.axiomatics.org/~gdr/liz/cicm-2012.pdf