3 ms·

inline constexpr auto for_each = []<Range R, Iterator I = iterator_t<R>, IndirectUnaryInvocable<I> Fun>(R&& r, Fun fun) requires Range<indir

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; }; Unless it solves world hunger or COVID permanently I am not typing this abomination, much less try to understand it. Very seriously whatever "team" is working on C++{20,21,..} should be disbanded and sent to someplace where they don't have access to computers. Nothing modern including Kubernetes ecosystem induces this much rage in me.

lionkor 5y ago
To be fair, you could write this in a more comprehensible way. I wouldn't say "Rust sucks" based on reading Err(Err::Error(Error::new("c1", ErrorKind::Digit)))); either, since I just assume its not the language's fault.
- blinkingled 5y ago
  I am a bit more willing to put up with Rust syntax monstrosities as at least the compiler tries to help me not shoot myself in the foot and when I try the error messages seem to be more helpful than C++ compliers'. Also I don't have as much of an issue with sane subset of C++ as a language - it's the modern crap they keep adding pompously without regard to complexity and usability that irks me.
- eska 5y ago
  That's not idiomatic code.
gpderetta 5y ago
That's the pedantically, fully reusable, correct version. Most of the time I would type something like this: template<Range R, class Fun> auto for_each(R&& range, Fun fun) { return std::forward<R>(r) | view::transform(std::move(fun)) | view::join; } I.e. I wouldn't bother to type check Fun and I would use a function instead of a function object. Both features are important for library code though. Forward and move are still pointlessly noisy, I wish there was a keyword for those (especially forward). And I wish we had proper UFC instead of abusing pipes.
- bfrog 5y ago
  Absolute rubbish readability
riskneutral 5y ago
I don't see the problem. It's a lambda function template using the std::ranges library's pipe style for algorithims. You are don't have to use the pipe style if you don't want to.

lionkor 5y ago

To be fair, you could write this in a more comprehensible way. I wouldn't say "Rust sucks" based on reading Err(Err::Error(Error::new("c1", ErrorKind::Digit)))); either, since I just assume its not the language's fault.

blinkingled 5y ago
I am a bit more willing to put up with Rust syntax monstrosities as at least the compiler tries to help me not shoot myself in the foot and when I try the error messages seem to be more helpful than C++ compliers'. Also I don't have as much of an issue with sane subset of C++ as a language - it's the modern crap they keep adding pompously without regard to complexity and usability that irks me.
eska 5y ago
That's not idiomatic code.

gpderetta 5y ago

That's the pedantically, fully reusable, correct version. Most of the time I would type something like this: template<Range R, class Fun> auto for_each(R&& range, Fun fun) { return std::forward<R>(r) | view::transform(std::move(fun)) | view::join; } I.e. I wouldn't bother to type check Fun and I would use a function instead of a function object. Both features are important for library code though. Forward and move are still pointlessly noisy, I wish there was a keyword for those (especially forward). And I wish we had proper UFC instead of abusing pipes.

bfrog 5y ago
Absolute rubbish readability

riskneutral 5y ago

I don't see the problem. It's a lambda function template using the std::ranges library's pipe style for algorithims. You are don't have to use the pipe style if you don't want to.