needs of an ISO process. You can build whatever process you want for it.
your concerns about the one you've been using for a quarter of a century.
It reads a little partisan I'm afraid.
and that dissenters are unwelcome.
Post by Nicol BolasPost by Ricardo Fabiano de AndradeEven though I totally disagree with Richard's tone in this discussion I
do understand his frustration with the current status quo of C++. I felt
like this myself in several occasions.
Despite my admiration for the members of the committee and all the effort
they put in the standard, I think there's plenty of room for improvement in
a few areas.
The most critical in my opinion is that the communication channel between
community and committee is too narrow and therefore the feedback is
insufficient.
There's no clear path for trying a new library or language features.
As example, it doesn't matter if string_view has been available for
several years if no one knows about it, which purpose is it supposed to
serve and how to use it.
It's very hard for someone that doesn't follow the standard to get to
know about a proposal and where to try it.
"Where to try it" is not something the standards committee can deal with.
The committee publishes standards, not implementations.
As for knowing about a proposal... I really don't know how much more the
committee can do. There's an entire website whose sole purpose is to be
where standard C++ news items happen. That website publishes the mailings,
which contain all of the proposals in question.
What more do you want?
People who want to affect the language should be expected to put forth the *minimal
effort* of paying attention to channels of information. I don't think
that's asking too much.
The committee is counting on volunteers but there's no effort to make this
Post by Ricardo Fabiano de Andradeneed explicit. Honestly, a language complex as C++ needs all the help one
can get.
And a language as complex as C++ needs as little of the *wrong* kind of
help as it can get. That's really important too.
On the contrary, the few channels available (this one and std proposals)
Post by Ricardo Fabiano de Andradeare very closed (and sometimes it feels unwelcoming) to the general
community.
I'm not sure how much more open you can get by having a forum/mailing list
that literally anybody can sign up to use. The forums may be well-hidden,
but once you find them, they're right here.
The community gets their hands on language and library changes very late
Post by Ricardo Fabiano de Andradein the process.
And boost can't serve much as a test bed because the experience has been
proving that once something from boost passes through the committee, a
whole lot changes.
Most of the record of such changes and decisions is closed to the general
community - because ISO doesn't allow that to be public in some cases.
The majority of the community is not interested in submitting proposals.
The bar is too high and it's too big of a commitment.
But everyone is eager to try the "next big thing". The current process is
missing all this participation.
I'm not sure how useful such participation would be. If you're not able to
put together a proposal... what exactly can you *do* to improve the
standard? Ideas are *easy*; it's the details that are hard. And it's the
*details* that we need.
Again, if you want some kind of collective proposal development system,
that's fine. But it still needs to lead to an actual proposal, not a bunch
of ideas or functions that someone else has to cobble together into a
working whole.
So what would this participation be, providing commentary on proposals?
That just requires people who have actual domain knowledge to spend their
time sifting through the 90% of worthless comments for the occasional
nugget of genuinely useful information. That is a huge waste of time.
Change is slow and corrections even slower.
Post by Ricardo Fabiano de AndradeThe 3-year cycle is an eternity in the current environment of software
development.
If what has been discussed here about string_view is really a problem it
may take up to absurd 9 years to fix the standard.
3 years to confirm it was a bad idea, then 3 deprecate in the next
standard, then 3 to remove on the next.
By that time Rust might have took over all native development! :-/
Worst of how much harm this can cause to the users of the language and to
the several applications plagued by it, it's how bad this is for the
reputation of C++.
Richard is right that all the good will and excitement brought by C++11
is being buried by what most of the community see as a bunch of bad moves
on the direction of C++.
Even though I don't share this point of view, I can't change how others
perceive past events.
I believe there's still time to get things right before C++ becomes the
new COBOL.
1) Break the standard in two - language and library - but not literaly.
Keep the 3-year cycle for language, have a much shorter (4-month /
per-meeting?) cycle for library changes.
How would that be anything other than a "literal" breaking of the standard
into two? You can't release a new version of part of a document.
Organize a different work group for the short cycle to not drawn resources
Post by Ricardo Fabiano de Andradeaway from the main work groups.
- Fixing defect reports
- Improve on usabiliy and ease-of-use issues (example: make_unique)
- Test library-only solutions that may demand languange additions not
certain to be worth
- Deprecating library features
- Remove deprecated library features
OK, let's wind the clocks back to 2011. C++11 is about to be published,
and you're going to deprecate `auto_ptr`. And this time, you're deprecating
it with the expressed idea of replacing it with `unique_ptr`. So you're
*serious* about it.
Now, forget everything about how long it takes to publish another
standard. If you had to pick a year, what year would you say "OK,
everyone's had enough time to switch to `unique_ptr`, so we're eliminating
`auto_ptr`"?
I submit that no year before 2016 is workable. You need to be fully aware
of just *how much C++ code* exists out there. And just how much of it
needs to compile and yet isn't being actively maintained.
And we're talking about a *drop in replacement* here, where any
differences between `auto_ptr` and `unique_ptr` will be obvious, noisy, and
quickly resolved. And some people still complain after *six years of
warning*.
To remove a more widely used feature would require at least as much time
if not more. So I fail to see how the 3 year period is a problem. You
cannot practically remove features that people are using like that. Not if
you want a language that works.
Post by Ricardo Fabiano de Andrade- Merging library TSs which do not require language changes
Then offload some of this work to the community.
You cannot publish an *international standard* based on random people on
the Internet.
One idea is having a centralized issue tracking where compiler and library
Post by Ricardo Fabiano de Andrademaintainers and users could post defects or ask for improvements.
2) Stop using std::experimental and instead use std::alpha / std::beta
(or anything that indicates how close such feature is to the final
standard).
Companies/teams would be more comfortable adopting and testing
pre-standard features.
Provide an easy to access matrix of these features but different of the
current one currently on isocpp.org that only contains the proposal
- Synopsis of motivation
- A collection of practical examples
- A history of the decisions around the design
- Such matrix could be maintained by the community similarly as the Core
Guidelines.
There's no way that's going to fit into a "matrix".
Consider `std::variant`. That proposal went through a *huge* number of
changes. And the proposals kept extensive notes documenting not only each
change, but the committee votes responsible for it. The history section for
some of those revisions required *pages*. You can't fit all of that into
a "matrix".
3) Library proposals should have standard implementations which compile in
Post by Ricardo Fabiano de Andradeall major compilers compliant with the targeted standard.
- I am aware this is close to a de facto requirement.
- But the change is that they would be centralized in a common repository.
- Library features could target an older standard if that makes sense.
- People not able or not willing to switch to a new standard could use
the standard implementation.
- A standard implementation would stop to be maintained once part of the
standard.
- If modified for adhering to a subsequent standard, it's assumed to be a
new proposal.
4) All the ideas above use, if you will, the "github" model for driving
the work around the standard.
But there's still room for a "StackOverflow" model to gauge interest
and/or indicate deficiencies in the final product.
As soon as the model above is available the parts of the library/language
- The "hot" features that everyone is looking into integrating in their
work.
- Or, the ones lacking documentation or too difficult to be used by the
average user of the language.
- StackOverflow itself can be used, no need to reinvent the will.
Those ideas aim to drive more people to participate in the new
"maintenance" work group as well in providing feedback.
Again, what kind of "participation" are you talking about? Before you can
start proposing solutions, you need to explain how, in your ideal world,
people would be materially contributing to C++.
Post by Ricardo Fabiano de AndradeThey centralize the efford to make the standard happen - a single source
of truth of sorts - that should be in the front page of isocpp.org.
I believe this also addresses the concerns of both the camp of "C++
evolution is sluguish" and the camp of "I can't keep up with C++".
Also, the experts are left alone to drive the evolution of the language
Post by Ricardo Fabiano de Andradeevery 3 years but they will be watched more closely by whole community
involved in maintaining the current standard.
All this is suplemental to the current communities revolving around C++
such as clang, gcc, boost, etc. They would feed from the "standard"
community and vice-versa.
That said, who's interested in convincing the committee and tackle this
challenge? :)
Fork Clang and libc++, and go start your own language split from the needs
of an ISO process. You can build whatever process you want for it.
--
---
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
Visit this group at https://groups.google.com/a/isocpp.org/group/std-
discussion/.