auto
is really nice to maintain a single definition and avoid some typing. It's also necessary for std::ranges::views
. However, auto
can make code harder to read it's too far from the defining type (particularly in code review). Replacing it with an explicit type can also validate that the type is what you expect (e.g. before passing it to a templated function and winding up in a world of template error message hurt). There needs to be a balance. Unfortunately, auto
is necessary for views
(I assume since the type is implementation dependent).
#include <ranges>
// Provided in some other header
template<class Range>
auto process(Range&& range)
{
return range | std::ranges::views::transform(&Foo::i);
}
// main.cpp
struct Foo { int i; };
void func()
{
Foo foos[4];
// What is result and what can you do with it?
auto result = process(foos);
}
Is there something I can replace auto
with that makes the type a bit more clear?
auto
? In the end it is a "how" not a "what", and usually something like intellisense can quickly show what the types is (just hover overresult
). – Cipherprocess()
to guess at whatresult
is - is it a primitive type, a container, who knows. Even then it may be a few definitions deep. Hovering over result in an editor doesn't help with complicated definitions such as those returned bystd::ranges::views
. You're exactly right though - I want to know what I can do with result and I don't mind so much about the exact type. – Servicemanviews
has a counterpart class suffixed with _view inranges
you can use that, and operand toreturn
becomes a bunch of nested braced initializers. But some CPOs don't correspond to a single class template, and you'd have to work your way. – Anthracene