Subject: Re: [boost] usage of auto in tutorials
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2019-03-19 10:25:45
Thanks for bringing this up. I am in part responsible for the documentation
of Outcome. I would like to know more about objections.
The initial page you linked to has the following two usages of auto:
auto process(const string& content) noexcept -> outcome::result<int>;
> if (auto rslt = read_data_from_file("config.cfg"))
Are you referring to these?
I agree that inside the if-statement it is better to spell the type explicitly.
However, the auto in the function declaration doesn't seem to do any
harm: it only allows me to put the return type at the end,
so there is no deduction that is taking place.
Are there any other usages of auto that cause your concern? In the
examples that I was able to have a look at autos are avoided, like:
There is one auto in the explanation of OUTCOME_TRY:
But in this case we are explaining what the macro expands to, and part
of the contract of the macro is that type deduction is performed,
so I guess the auto fits better.
I agree with the observation that autos for type deduction have better
be avoided. It is just that I consider some of the cases special.
Let me know what you think of my explanations.
wt., 19 mar 2019 o 08:12 Stephan Menzel via Boost <boost_at_[hidden]>
> Hello all,
> I was eagerly awaiting the release of the 1.70 beta, especially for
> outcome, which I have much use for, having lots of async functionality.
> While looking at the tutorial here that
> I notice that auto is used instead of the types. Is there a background to
> I question if this is such a good thing in tutorials. The first thing I
> like to know about a new lib is the types and classes it offers and auto
> obfuscates this.
> Is there any consensus in the boost community as to how and if tutorials
> and docs should use auto? I have concerns about this and feel it doesn't
> increase the otherwise great quality of documentation and tutorials for new
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk