It probably is, but the analogy is still fairly apt IMO. You can't rely on people to complain *before* you make their lives harder. The onus is on you to do due diligence, and if you don't you can't wash your hands of the criticism that arrives when people notice...
-
-
Replying to @ssylvan @Timewatcher and
What I did what take a library that had been popular for 15+ years (Boost.Range) and that directly addressed two of the biggest gripes against the Standard Library: terrible error messages and poor usability of the algorithms; modernized and standardized it. 1/2
1 reply 0 retweets 7 likes -
Replying to @ericniebler @ssylvan and
To say that I was merely pushing my own agenda to indulge my ego without any consideration of the needs of the community is to demonstrate the same lack of curiosity that I have been accused of in this thread. 2/2
1 reply 0 retweets 9 likes -
Replying to @ericniebler @Timewatcher and
I don't know much about Boost.Ranges specifically, but serious question: are you unaware that many of use would rather eat glass than include Boost in our projects? It's a highly divisive library at best. Maybe ranges is the rare jewel in there, but it doesn't seem like a...
2 replies 0 retweets 5 likes -
Replying to @ssylvan @ericniebler and
... flawless strategy to use Boost as a proving ground for new C++ features. And the example you used to motivate it is exactly the kinds of horrors people dislike and mock about Boost. Perhaps not every new feature has to be a library?
3 replies 0 retweets 1 like -
Replying to @ssylvan @Timewatcher and
Put it in the language (for any "it") and there is a hue and cry about bloating the language. Do nothing and there is a cry about stagnation. std::function, shared/weak/unique_ptr, optional, type traits; all good additions proven first in Boost.
1 reply 0 retweets 3 likes -
Replying to @ericniebler @ssylvan and
<type_traits> is a great example of the wrong practice getting standardized, and getting standardized in ridiculous ways. Consider this: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2518.html … ... which was appreciated by every C++ compiler vendor I talked to back in 2008, but rejected by EWG.
1 reply 0 retweets 1 like -
Replying to @JamesWidman @ericniebler and
...which is kind of nutty because, here we have this library that _can't_ work without those built-in operators, and yet the header pretty much mainly serves to wrap the operators.
1 reply 0 retweets 0 likes -
Replying to @JamesWidman @ericniebler and
So why even make the rest of the library depend on <type_traits> when they could just use built-in operators directly (which would be faster, use less memory, and cause fewer cache evictions than generating loads of instantiations of the templates declared in <type_traits>)?
2 replies 0 retweets 0 likes -
Replying to @JamesWidman @ericniebler and
The worst part is that various library vendors valiantly tried to avoid depending on (or asking for) some or all of the builtins, and instead came up with clever, slow, and subtly wrong ways of computing the same thing in pure C++...
1 reply 0 retweets 2 likes
The committee has always been deluded that std is part of the language. C++ must be a complete language without std. C++ will far outlive std. We must always ensure the language is complete, as a succession plan anticipating the eventual demise of std.
-
-
Replying to @TimSweeneyEpic @zygoloid and
We say “core language” when excluding the standard library, but yes. And I sincerely regret that I didn’t understand this in 2006 when std::initializer_list made its way through CWG.
1 reply 0 retweets 1 like -
Replying to @JamesWidman @TimSweeneyEpic and
(Though on second thought, the fact that we even see a distinction between “language” and “core language” demonstrates the problem you’re talking about.)
0 replies 0 retweets 0 likes
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.