Post by Nevin LiberPost by Nicol BolasThe problem with the "evolutionary path" approach is that the standards
committee is notoriously *lazy* about these things.
We are? I take offense at that.
Post by Nicol BolasRemember 'final' and 'override'? Well, they were part of an entire
package designed to make derived classes much safer to implement. There was
going to be a mechanism to decorate a class definition so that the compiler
would *enforce* the usage of 'override' for virtual functions that were
meant to override base class virtuals. And similar constructs, all intended
to ensure more safety in this domain.
The committee works on proposals. If the people who were passionate about
those features are no longer passionate enough about them to present a
proposal addressing all the concerns that came up, well, what should the
committee do? Get volunteers to somehow work on stuff no one thinks is a
priority? People would then complain, probably on this very list, that we
are wasting our time.
And if you think this is so darn important, why aren't you doing the
work? If you believe we should get volunteers to do this work, then I
nominate you as that volunteer.
On the flip side, people were passionate about removing trigraphs,
auto_ptr, random_shuffle, unary_function, binary_function, ptr_fun, mem_fun
and mem_fun_ref, and they will be gone as of C++17.
Post by Nicol BolasWe'll likely see something similar with concepts. Oh, we'll get checking
at instantation time. But checking expressions within the template
implementation, to see if they conform to the requirements of the concept?
That's too hard. Concept mapping? Nope, too hard.
I look forward to seeing your proposal and implementation proving this
wrong.
Post by Nicol BolasIn general, when I hear people talking about an "evolutionary path", what
I translate that to is, "We won't *actually* fix the problem. We'll
solve *just enough* of the problem to get you to shut up, then hope
you'll go away before you make us do the hard part."
In general, whining on an email list about is easy; writing and revising
proposals and coming to multiple meetings to push them through is the hard
part and not at all lazy.
Post by Nicol BolasIf there's no commitment or follow-through by the committee on the
"evolutionary path", I'd really rather they just not bother.
Do you feel the same way about people who spend their time griping on
mailing lists instead of committing and following through to writing and
championing actual proposals?
--
I don't think I explained myself very well. Perhaps a counter-example is in
order. That is, an example of the committee *not* being lazy.
Consider Herb Sutter's idea for a standardized "Lightweight Drawing
Library". He issued an outline of what he wanted. The problem is that,
well, he doesn't know much about this sort of thing. However, he didn't
follow the standard committee process of, "Gee, I hope that someone comes
along and writes a proposal. And attends meetings. And gets feedback and
writes new versions of the proposal. For years. Until hopefully it makes it
through."
In his capacity as a member of the C++ standards committee (and a major
person in the C++ scene), he actually sought out experts in this domain. He
went out and found people to write a proposal. He used his influence to cut
through the general red tape that surrounds committee proposals and ensure
that this would actually happen.
To be sure, it's not done yet. But my point is this. This isn't like
Stroustrup and concepts; there, he is the primary designer of the feature
as well as the one with the will to see it done. Herb took on the
responsibility, not to develop the feature, but to see to it that the
feature *gets developed*. He's pushing for it, and he will continue to do
so. If the current guys become disinterested, Herb will find someone else
to carry on.
The members of the standards committee should be doing more than just
reacting to proposals. They need to be actively trying to develop specific
features that improve C++ in various ways. They should be looking at where
C++ is deficient and working to resolve those deficiencies.
The study groups are one way, but they are too reactive. Study groups are
formed due to a critical mass of expertise on a complex subject. They
aren't formed in advance of such a critical mass; they aren't formed to
*create* such a critical mass. There's no process for actually creating
such a state.
The committee should have initiatives like Herb's, drives to push towards
some specific end. The committee's current process only reacts to
proposals; it doesn't proactively seek out solutions to specific C++
problems. What Herb did is the exception rather than the rule.
I consider this passive approach to be lazy: it puts all of the work is on
the *proposer*, not the committee. Even the desire for the feature is on
the proposer, not the committee (even if the proposer happens to be on the
committee). If the proposer doesn't show up after the commentary on the
proposer, then it just doesn't get done.
My favorite example of this is the proposal for Unicode library support in
C++. It was pretty comprehensive, ranging from specialized iterators to
string types, with Unicode normalization, and lots of other features. It
effectively died on the vine. There was a proposal, it was reviewed (IIRC,
the proposer wasn't able to attend, and had some trouble getting accurate
feedback about what happened), and... that was it. Eventually, despite
clearly having both an interest in the feature and some knowledge on the
subject, he just seemed to give it up as a bad job.
Unicode in C++ is an important problem. It is of sufficient importance that
the committee *itself* should have shown the initiative to make sure that
it gets solved. If one person didn't want to continue the proposal, another
interested expert should have been *sought out*, rather than them simply
waiting and hoping such a person would appear. The committee should have
been proactive in providing whatever support was needed to keep the
proposal moving and progressing. And if it wasn't progressing fast enough
or if the original person wanted to stop, the committee should have gone
out to find someone else to do it.
I see a lot of statements saying that there weren't enough/any proposals on
it, or that the proposer didn't come to meetings, or the proposer gave up
and it withered, or whatever. I hear a lot of talk from committee members
about welcoming proposals.
Yet I see little effort from them to actively seek them out. I see very
little *leadership* from the committee on several fronts in C++. I
mentioned Herb's example in part because it very much seems like the only
time I've seen someone on the committee take up a leadership role by
seeking out experts, rather than being one.
Maybe this is due to ISO rules or whatever. It doesn't really matter why
the status quo exists. What matters is that C++ is largely developed by
hoping that someone will manage to navigate the Byzantine process of
standardization with a proposal that accomplishes something useful. All
reactive, nothing proactive.
And so long as the committee remains non-proactive, there's no reason to
expect any "evolutionary path" to actually be followed. They'll adopt step
1, without any obligation or responsibility to even consider steps 2 or 3.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.