I have filed a pull request which remove autos from the intro page: https://github.com/ned14/outcome/commit/69be40f942b662516016a203fc74ade1a0a8... 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@lists.boost.org> napisał(a):
Hello Andrzej,
On Tue, Mar 19, 2019 at 10:26 AM Andrzej Krzemienski via Boost < boost@lists.boost.org> 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/e...
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/e...
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