Re: [boost] usage of auto in tutorials

Subject: Re: [boost] usage of auto in tutorials
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2019-03-19 22:17:39

I have filed a pull request which remove autos from the intro page:
https://github.com/ned14/outcome/commit/69be40f942b662516016a203fc74ade1a0a81051
1.70 is open for bugfixes, so adding documentation changes should still be
possible.

Regards,
Andrzej

wt., 19 mar 2019 o 11:59 Stephan Menzel via Boost <boost_at_[hidden]>
napisał(a):

> Hello Andrzej,
>
> On Tue, Mar 19, 2019 at 10:26 AM Andrzej Krzemienski via Boost <
> boost_at_[hidden]> wrote:
>
> >
> > 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.
> >
>
> Mostly, yes. I do understand what the code does but it kind of forces me to
> do the mental indirection when reading. I do understand the trailing return
> type syntax and why one could use auto there.
> But for some people this looks very unusual. For example, because they are
> not aware of this new syntax or they have not applied it and still write
> functions the old fashioned way. Some (like me) work in environments where
> the use of auto is banned altogether.
> I'm not arguing pro or contra auto or trailing return types or indeed even
> the runtime implications.
> All I'm saying is, for a tutorial I feel one should choose a simple way of
> expressing things with a high likelyhood of being understood by many
> immediately.
> Especially here where the actual return type is the most interesting part
> as the lib is essentially about returning things. Having it as the first
> part of a statement would help.
>
>
> > 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:
> >
> >
> https://www.boost.org/doc/libs/1_70_0_beta1/libs/outcome/doc/html/tutorial/essential/result/inspecting.html
>
>
> Yes, I just had a look atother parts of the tutorial and I find others
> easier to read. OK, I'm an old fashioned guy and I know these days some
> folk have other ways of coding but the quick start tutorial should be as
> simple as possible.
>
>
> > There is one auto in the explanation of OUTCOME_TRY:
> >
> >
> https://www.boost.org/doc/libs/1_70_0_beta1/libs/outcome/doc/html/tutorial/essential/result/try.html
> >
> > 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.
> >
>
> Yes it does. I think parts of the tutorial may and should go into the
> 'fancy new stuff' and take advantages of newer language features. No
> problem there. Thanks for understanding my concerns. I'm going to have a
> close look at outcome as soon as 1.70 releases. I was looking forward to it
> ever since I used the outcome implementation in the AWS SDK. Which is
> incredibly header intensive and cumbersome in my opinion but interface wise
> not too far from what you do. I was curious to see Boost's take on this.
>
> Cheers,
> Stephan
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>