4 ms·

Having switched away from C++, I've got the feeling that this kind of code: inline constexpr auto for_each = []<Range R, Iterator I = iterator_t<R>,

Having switched away from C++, I've got the feeling that this kind of code: inline constexpr auto for_each = []<Range R, Iterator I = iterator_t<R>, IndirectUnaryInvocable<I> Fun>(R&& r, Fun fun) requires Range<indirect_result_t<Fun, I>> { return std::forward<R>(r) | view::transform(std::move(fun)) | view::join; }; is a sort of magical incantation you spend 3 days to tweak, it essentially just works, but becomes un-understandable within 2 weeks (even from the author), un-reviewable and code that everybody is afraid to touch (or even get close to) ? Don't get me wrong, there is definitively a lot of flexibility I'm missing from C++, even the problem can be addressed otherwise with other language, but things can get very, if not utterly... convoluted.

htfy96 8y ago
This should be a library function that will not be exposed directly to most developers, who only need to know for_each(Range, fun) which is pretty straightforward.
- alacombe 8y ago
  people will end up using that... A former colleague spent a week simplifiying a 10 lines templates to use C++14's std::integer_sequence, nobody could review his code. Doesn't really matter at the end. I'm fairly certain the code in question was canned later on by more "old school" devs...
- DoofusOfDeath 8y ago
  I've heard that line of reasoning before, and it doesn't make sense to me. Specifically, I find it alarming that it assumes two tiers of competent c++ developers: a lower tier that just uses libraries, and a higher tier that can write good libraries. I see two problems with this view. First, in my experience most large codebases are structured as many layes of libraries. So the envisioned non-library developer may be in the minority. Second, it's a red flag that the language's complexity dangerously high. If nothing else, one of the envisioned non-library developers may unwittingly write code that uses or misuses these features, and still need to debug incomprehensible compilation- or runtime-errors.
  - saagarjha 8y ago
    > If nothing else, one of the envisioned non-library developers may unwittingly write code that uses or misuses these features, and still need to debug incomprehensible compilation- or runtime-errors. The reason that the code is this complicated is so that end users don’t shoot themselves in the foot (performance-wise, correctness-wise) when using these features. And error messages will get better when concepts land. To address your main point, though: there is always a separation between library authors and library consumers, even if they are written by the same people, because the requirements are different in each case. A library author must write general and useful code, while a library user can “get away with” hard coding logic and customizing uses to only cover what they need. Hence, the job of a library author is usually much harder.

htfy96 8y ago

This should be a library function that will not be exposed directly to most developers, who only need to know for_each(Range, fun) which is pretty straightforward.

alacombe 8y ago
people will end up using that... A former colleague spent a week simplifiying a 10 lines templates to use C++14's std::integer_sequence, nobody could review his code. Doesn't really matter at the end. I'm fairly certain the code in question was canned later on by more "old school" devs...
DoofusOfDeath 8y ago
I've heard that line of reasoning before, and it doesn't make sense to me. Specifically, I find it alarming that it assumes two tiers of competent c++ developers: a lower tier that just uses libraries, and a higher tier that can write good libraries. I see two problems with this view. First, in my experience most large codebases are structured as many layes of libraries. So the envisioned non-library developer may be in the minority. Second, it's a red flag that the language's complexity dangerously high. If nothing else, one of the envisioned non-library developers may unwittingly write code that uses or misuses these features, and still need to debug incomprehensible compilation- or runtime-errors.
- saagarjha 8y ago
  > If nothing else, one of the envisioned non-library developers may unwittingly write code that uses or misuses these features, and still need to debug incomprehensible compilation- or runtime-errors. The reason that the code is this complicated is so that end users don’t shoot themselves in the foot (performance-wise, correctness-wise) when using these features. And error messages will get better when concepts land. To address your main point, though: there is always a separation between library authors and library consumers, even if they are written by the same people, because the requirements are different in each case. A library author must write general and useful code, while a library user can “get away with” hard coding logic and customizing uses to only cover what they need. Hence, the job of a library author is usually much harder.