[libcxx-commits] [PATCH] D113906: [libc++] [test] Add "robust_re_difference_type.compile.pass.cpp" for all the algorithms.
Arthur O'Dwyer via Phabricator via libcxx-commits
libcxx-commits at lists.llvm.org
Tue Nov 16 11:28:31 PST 2021
Quuxplusone added inline comments.
================
Comment at: libcxx/test/std/algorithms/robust_against_adl.compile.pass.cpp:60
+#endif
+ (void)std::generate(first, last, [](){ return nullptr; });
+ (void)std::generate_n(first, count, [](){ return nullptr; });
----------------
var-const wrote:
> Quuxplusone wrote:
> > var-const wrote:
> > > Ultranit: omit the empty parentheses?
> > Definitely not. :)
> Just curious, what's your rationale? I've always seen them as unnecessary boilerplate, so I'm interested to know why you prefer to keep them. To be clear, I'm absolutely fine with keeping them, just interested in your perspective.
I've always seen the extra parser codepath that says "Lambdas look like this, //except// that if the function parameter list is empty, you can omit it" (specially for lambdas — ordinary functions' parameter lists can't be omitted) as unnecessary //complication// added to an otherwise relatively clean design.
I don't teach people that the special case exists, and my impression is that nobody ever discovers it on their own. (Because why would anyone ever try //omitting// a function's parameter-list? nobody should //expect// that to work!)
(The other lambda snafu of which I'm aware is that `[x, y, &]() { }` is ill-formed — the correct syntax places the default //first//, not last: `[&, x, y]() { }`. That's marginally more discoverable by newbies, but still a relative corner case, because 99% of the time, you want `[&]`, and if the compiler stops you from writing `[x,&]` or `[&x,=]` with a [cryptic error message](https://godbolt.org/z/ch4Kona6s), well, strewing the road with nails is //one// way to discourage people from going down it. ;)
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D113906/new/
https://reviews.llvm.org/D113906
More information about the libcxx-commits
mailing list