usage of auto in tutorials

Stephan Menzel

19 Mar 2019 19 Mar '19

7:11 a.m.

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 https://www.boost.org/doc/libs/1_70_0_beta1/libs/outcome/doc/html/index.html I notice that auto is used instead of the types. Is there a background to this? 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 libs. Cheers, Stephan

Show replies by date

Andrzej Krzemienski

19 Mar 19 Mar

10:25 a.m.

Hi Stephan, 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: https://www.boost.org/doc/libs/1_70_0_beta1/libs/outcome/doc/html/tutorial/e... 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. 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. Regards, Andrzej wt., 19 mar 2019 o 08:12 Stephan Menzel via Boost napisał(a):

...

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

https://www.boost.org/doc/libs/1_70_0_beta1/libs/outcome/doc/html/index.html I notice that auto is used instead of the types. Is there a background to this? 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 libs.

Cheers, Stephan

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Stephan Menzel

10:59 a.m.

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

mike.dev＠gmx.de

3:36 p.m.

...

-----Original Message----- From: Boost On Behalf Of Stephan Menzel via Boost

My personal rule of thumb for tutorial and demos is similar to how you handle abbreviations in written text: First time you e.g. use a function, you explicitly show what the function returns. Afterwards I use auto where it makes sense (And yes, I know there are conflicting opinions about "where it makes sense"). With respect to the specific examples: - Trailing return types in function declarations: If the style guide doesn't say something different, I only use them for very long type names and when they are needed. None of this applies here, so I don't see the benefit, but also not any harm. I'd say it is personal/project preference. - The auto inside the if: The return type of the function is shown just two lines above. Again, personal opinion, but I'd claim it even increases readability, because it is less visual noise. \rant on

...

[...]

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.

As I wrote, I rarely use trailing return types and I'm generally no advocate of using auto everywhere, but this "new" syntax has been valid c++ for more than half a decade now. If a professional c++ programmer is still unfamiliar with this, then maybe more exposure to it is actually a good thing and if boost doesn't spread the word who does? Also, where does this end? Should tutorials stay away from rang based for loops? Smart pointers? Templates? Namespaces? C++ features all together? I know I'm exaggerating a bit, but I think it is a valid question. From the perspective of a c programmer, all those things are "new". However, outcome is a c++14 library so using c++14 features "where they are usefull" should not be avoided, but embraced. Again, I'm not suggestion auto should be used everywhere, because it really can decrease readability significantly, but imho example code (regardless of the context) should reflect current best practice and not based on guesswork about what language the users might be most familiar with. Don't be afraid of change. \ rant off Mike

Andrzej Krzemienski

3:49 p.m.

wt., 19 mar 2019 o 16:37 mike via Boost napisał(a):

...

...
-----Original Message----- From: Boost On Behalf Of Stephan Menzel via Boost

My personal rule of thumb for tutorial and demos is similar to how you handle abbreviations in written text:

First time you e.g. use a function, you explicitly show what the function returns. Afterwards I use auto where it makes sense (And yes, I know there are conflicting opinions about "where it makes sense").

With respect to the specific examples: - Trailing return types in function declarations: If the style guide doesn't say something different, I only use them for very long type names and when they are needed. None of this applies here, so I don't see the benefit, but also not any harm. I'd say it is personal/project preference. - The auto inside the if: The return type of the function is shown just two lines above. Again, personal opinion, but I'd claim it even increases readability, because it is less visual noise.

\rant on

...
[...]

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.

As I wrote, I rarely use trailing return types and I'm generally no advocate of using auto everywhere, but this "new" syntax has been valid c++ for more than half a decade now. If a professional c++ programmer is still unfamiliar with this, then maybe more exposure to it is actually a good thing and if boost doesn't spread the word who does?

There two sides to it. Yes, it is good to highlight new language features, and how they can be used. But it may conflict with the objectives of a tutorial, especially the initial page: the potential user should get the picture how (s)he will be using the library, as fast as possible. This may be the matter of seconds. If we put off the potential user too much in this step, (s)he is likely to drop our library and go to the competition or go to manually write a similar (but lower quality) tool because determining whether our library does what is needed took too long.

...

Also, where does this end? Should tutorials stay away from rang based for loops? Smart pointers? Templates? Namespaces? C++ features all together?

I know I'm exaggerating a bit, but I think it is a valid question. From the perspective of a c programmer, all those things are "new". However, outcome is a c++14 library so using c++14 features "where they are usefull" should not be avoided, but embraced.

Again, I'm not suggestion auto should be used everywhere, because it really can decrease readability significantly, but imho example code (regardless of the context) should reflect current best practice and not based on guesswork about what language the users might be most familiar with.

I wonder what others in this group think? Maybe we could come up with some guidelines for documentation writers. Regards, &rzej;

...

Don't be afraid of change.

\ rant off

Mike

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Paul A. Bristow

6:07 p.m.

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Andrzej Krzemienski via Boost Sent: 19 March 2019 15:49 To: boost@lists.boost.org Cc: Andrzej Krzemienski Subject: Re: [boost] usage of auto in tutorials

wt., 19 mar 2019 o 16:37 mike via Boost napisał(a):

...
...
-----Original Message----- From: Boost On Behalf Of Stephan Menzel via Boost

My personal rule of thumb for tutorial and demos is similar to how you handle abbreviations in written text:

First time you e.g. use a function, you explicitly show what the function returns. Afterwards I use auto where it makes sense (And yes, I know there are conflicting opinions about "where it makes sense").

With respect to the specific examples: - Trailing return types in function declarations: If the style guide doesn't say something different, I only use them for very long type names and when they are needed. None of this applies here, so I don't see the benefit, but also not any harm. I'd say it is personal/project preference. - The auto inside the if: The return type of the function is shown just two lines above. Again, personal opinion, but I'd claim it even increases readability, because it is less visual noise. <snip>

...

I wonder what others in this group think? Maybe we could come up with some guidelines for documentation writers.

I think that auto should be used sparingly in examples whose purpose is tutorial. Examples of where one *must use auto* are the exception rather than the rule, and usually worthy of special note. The main benefit of auto is 'syntactic sugar' for the writer, not the reader. Spelling out the type is usually an important part of illustrating the example. My 2p FWIW. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

Andrzej Krzemienski

8:52 p.m.

wt., 19 mar 2019 o 19:07 Paul A. Bristow via Boost napisał(a):

...

...
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Andrzej Krzemienski via Boost Sent: 19 March 2019 15:49 To: boost@lists.boost.org Cc: Andrzej Krzemienski Subject: Re: [boost] usage of auto in tutorials

wt., 19 mar 2019 o 16:37 mike via Boost napisał(a):

...
...
-----Original Message----- From: Boost On Behalf Of Stephan Menzel via Boost

My personal rule of thumb for tutorial and demos is similar to how you handle abbreviations in written text:

First time you e.g. use a function, you explicitly show what the function returns. Afterwards I use auto where it makes sense (And yes, I know there are conflicting opinions about "where it makes sense").

With respect to the specific examples: - Trailing return types in function declarations: If the style guide doesn't say something different, I only use them for very long type names and when they are needed. None of this applies here, so I don't see the benefit, but also not any harm. I'd say it is personal/project preference. - The auto inside the if: The return type of the function is shown just two lines above. Again, personal opinion, but I'd claim it even increases readability, because it is less visual noise. <snip>

...
I wonder what others in this group think? Maybe we could come up with some guidelines for documentation writers.

I think that auto should be used sparingly in examples whose purpose is tutorial.

An auxiliary question: does your guideline apply to `auto` used for type inference, or does it also apply to `auto` for trailing return type (where no deduction takes place). Regards, Andrzej

...

Examples of where one *must use auto* are the exception rather than the rule, and usually worthy of special note.

The main benefit of auto is 'syntactic sugar' for the writer, not the reader.

Spelling out the type is usually an important part of illustrating the example.

My 2p FWIW.

Paul

--- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Mike

6:18 p.m.

...

Gesendet: Dienstag, 19. März 2019 um 16:49 Uhr Von: "Andrzej Krzemienski via Boost"

wt., 19 mar 2019 o 16:37 mike via Boost napisał(a):

...
...
-----Original Message----- From: Boost On Behalf Of Stephan Menzel via Boost

My personal rule of thumb for tutorial and demos is similar to how you handle abbreviations in written text:

First time you e.g. use a function, you explicitly show what the function returns. Afterwards I use auto where it makes sense (And yes, I know there are conflicting opinions about "where it makes sense").

With respect to the specific examples: - Trailing return types in function declarations: If the style guide doesn't say something different, I only use them for very long type names and when they are needed. None of this applies here, so I don't see the benefit, but also not any harm. I'd say it is personal/project preference. - The auto inside the if: The return type of the function is shown just two lines above. Again, personal opinion, but I'd claim it even increases readability, because it is less visual noise.

\rant on

...
[...]

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.

As I wrote, I rarely use trailing return types and I'm generally no advocate of using auto everywhere, but this "new" syntax has been valid c++ for more than half a decade now. If a professional c++ programmer is still unfamiliar with this, then maybe more exposure to it is actually a good thing and if boost doesn't spread the word who does?

There two sides to it. Yes, it is good to highlight new language features, and how they can be used.

Thats just it: auto is NOT a new language feature. Certainly not in the context of a project that uses a c++14 library like outcome.

...

But it may conflict with the objectives of a tutorial, especially the initial page: the potential user should get the picture how (s)he will be using the library, as fast as possible.

Absolutely, but who is to say that isn't just how most users will use the library?

...

This may be the matter of seconds. If we put off the potential user too much in this step, (s)he is likely to drop our library and go to the competition or go to manually write a similar (but lower quality) tool because determining whether our library does what is needed took too long.

To repeat my position: If you think that a particular use of [language feature X] is confusing for potential users and there is an alternative solution that is less confusing and results in a similar amount of code then sure, use that. All I'm saying is that I don't agree with the premisis of "Any feature that was not in C++98/C90 is automatically more confusing for the "average" user". I can write absolutely confusing code in c++98 (and many boost libraries do just that internally) just as easily as in c++17. Maybe I'm biased, because I'm mainly working with people who haven't already spent decades writing C or or C with classes and just now have to adopt to "new" c++11 features. On the contrary: By now I believe I've written significantly more c++11/14/17 code than c++98. So I my experience might not be representative, but I don't think it is an exception either.

...

...
Also, where does this end? Should tutorials stay away from rang based for loops? Smart pointers? Templates? Namespaces? C++ features all together?

I know I'm exaggerating a bit, but I think it is a valid question. From the perspective of a c programmer, all those things are "new". However, outcome is a c++14 library so using c++14 features "where they are usefull" should not be avoided, but embraced.

Again, I'm not suggestion auto should be used everywhere, because it really can decrease readability significantly, but imho example code (regardless of the context) should reflect current best practice and not based on guesswork about what language the users might be most familiar with.

I wonder what others in this group think? Maybe we could come up with some guidelines for documentation writers.

Me too, I'm only voicing a single (probably biased) opinion here. Thats not something you want to base your decision on.

...

Regards, &rzej;

...
Don't be afraid of change.

\ rant off

Mike

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Stephan Menzel

7:38 p.m.

On Tue, Mar 19, 2019 at 4:49 PM Andrzej Krzemienski via Boost < boost@lists.boost.org> wrote:

...

There two sides to it. Yes, it is good to highlight new language features, and how they can be used. But it may conflict with the objectives of a tutorial, especially the initial page: the potential user should get the picture how (s)he will be using the library, as fast as possible.

Yes, this is exactly my point. I may have been unclear about this, given this thread. I am not advocating in favor or against any new language feature. Trainling return types, auto, whatever. Tutorials may show that. But the initial page has the purpose of showing at a glance what the lib is about and reach as many as possible. This is best achieved by a low common denominator. This may be the matter of seconds.

...

If we put off the potential user too much in this step, (s)he is likely to drop our library and go to the competition or go to manually write a similar (but lower quality) tool because determining whether our library does what is needed took too long.

Well, truth be told, I was on the verge. The most recent new lib I planned to adopt was spirit 3x, as I am a long time user of spirit 2 and wanted to see how the new one rolls. So I had a look and quickly found out that spirit 3x is done in a way that it essentially requires the use of auto. No reasonable way around it. And since auto is banned in my department, I had to abandon 3x. Which isn't too bad per se but when I briefly glanced over the outcome tutorial my first impression was "Oh, another one of those auto only libs...". I did realize my mistake quickly but it kinda proves your point to me. Which is why I wrote. Cheers, Stephan

Robert Ramey

8:10 p.m.

On 3/19/19 8:49 AM, Andrzej Krzemienski via Boost wrote:

...

I wonder what others in this group think? Maybe we could come up with some guidelines for documentation writers.

Regards, &rzej;

FWIW - my personal rule is to never use auto. The type conveys information. I think hiding information is a bad idea in general. (note before anyone complains: hiding information is not the same as abstracting and interface). auto is hack to permit one to work around some unfortunate situation which might occur while engaged in Template MetaProgramming. I haven't kept track, but I've found it necessary in probably less than 10 cases over the years. (Almost) Never use auto!) Robert Ramey

Andrzej Krzemienski

9:08 p.m.

wt., 19 mar 2019 o 21:10 Robert Ramey via Boost napisał(a):

...

On 3/19/19 8:49 AM, Andrzej Krzemienski via Boost wrote:

...
I wonder what others in this group think? Maybe we could come up with some guidelines for documentation writers.

Regards, &rzej;

FWIW - my personal rule is to never use auto.

The type conveys information. I think hiding information is a bad idea in general. (note before anyone complains: hiding information is not the same as abstracting and interface).

auto is hack to permit one to work around some unfortunate situation which might occur while engaged in Template MetaProgramming. I haven't kept track, but I've found it necessary in probably less than 10 cases over the years.

(Almost) Never use auto!)

I subscribe to rule "almost never auto"; but by this I mean "do not use type inference when you can spell out your type explicitly".

I never suspected that the feature known as "trailing return type", like ``` auto Class::fun() -> value_type; ``` would be questioned as unfit for tutorials. I am quite surprised that in Stephan's environment "auto" is banned regardless if it is used for type inference or for trailing return types. Regards, &rzej;

Gavin Lambert

11:19 p.m.

On 20/03/2019 10:08, Andrzej Krzemienski wrote:

...

...
I subscribe to rule "almost never auto"; but by this I mean "do not use type inference when you can spell out your type explicitly".

I never suspected that the feature known as "trailing return type", like

``` auto Class::fun() -> value_type; ```

would be questioned as unfit for tutorials. I am quite surprised that in Stephan's environment "auto" is banned regardless if it is used for type inference or for trailing return types.

Interestingly, I have the exact opposite rule. I never ever use trailing return types (unless absolutely required by arcane template rules), as I don't believe they provide any clarity (and in fact provide more obscurity for those less familiar with the syntax). Meanwhile in general I consider using auto for type inference a very good thing, especially in the context of "don't particularly care" nested types such as iterators. (There are a few exceptions, where it is useful to specify the type explicitly so that the compiler will warn you if someone later changes the type. And I never use it with primitive value types (int/float), as that's the most dangerous source of type surprises.) I'm also fond of using auto to DRY when calling factory methods such as make_unique and make_shared. For the purposes of writing a tutorial, however, I would encourage minimising use of auto (if not avoiding it altogether), both for explicitness of the example (which aids readability when you don't have an IDE doing auto-complete for you) and because if it becomes too cumbersome to spell out the types in your own examples, it might be a sign that your type names are wrong.

Joseph Van Riper

20 Mar 20 Mar

9:43 a.m.

...

...
Also, where does this end? Should tutorials stay away from rang based for loops? Smart pointers? Templates? Namespaces? C++ features all together?

I know I'm exaggerating a bit, but I think it is a valid question. From the perspective of a c programmer, all those things are "new". However, outcome is a c++14 library so using c++14 features "where they are usefull" should not be avoided, but embraced.

Again, I'm not suggestion auto should be used everywhere, because it really can decrease readability significantly, but imho example code (regardless of the context) should reflect current best practice and not based on guesswork about what language the users might be most familiar with.

I wonder what others in this group think? Maybe we could come up with some guidelines for documentation writers.

(I apologize for losing the attributions, but I wanted to keep focus). I have a love-hate relationship with the 'auto' keyword. For those times I find it difficult to work out the immediate type I should use, copping out with 'auto' gets me to where I need to go, so I find it 'productive', in the sense that if I need to get something done and I can't work through the maze of types that crop up occasionally, then I love it. I especially love it when dealing with iterators and funky derived types implied by who-knows-what consequences introduced through aggressive templating without establishing typedefs to assist the poor sod stuck with working out the type. Or really terrible documentation that doesn't explain that there is a typedef to assist you. For those times when I really want to understand the code I'm using, though, I despise it, because it simply hides that information away, and a lazy developer can just use it without concern, never really understanding what is happening, which I don't regard as helpful. Also, I have run into production code using the auto keyword in ways that created problems for us as the code shifted and changed. The developer used it to create the variables used within a for loop, and when the types shifted (perhaps to use a different container, I forget the details now), and the auto keyword resolved to a different type, it no longer worked properly for some of the code within the for loop... probably because the compiler had a choice of types it could resolve to, and chose poorly for our needs. Interestingly, had the developer used the actual type he intended, the iterator he intended would have worked within the for loop without issue. So, yeah, I'm hot and cold about its use in production code, generally. Useful when you need it, but can become a terrible crutch. If I were to offer a guideline, I'd pick up on what someone else wrote in this thread, and use it only after the type was clearly spelled out for reader. I'd use it within the same document, not buried in some other page in some obscure area where the developer may have missed it because s/he was focused on solving a specific issue and skipped most of the documentation to focus on their specific issue. That is, I'd take a cue from journalists here, and treat it was you might treat an abbreviation, since in C++ it sorta functions that way. This way, you highlight that the auto keyword exists in the language, you keep the documentation from becoming needlessly wordy, yet still help show the reader what the type should be so if they would prefer not to use auto, the documentation helps them figure out what type they should use. It also has the added benefit of forcing the developer to consider the need for a typedef to keep the use of their code from being too cumbersome (since if it's too wordy for documentation, imagine what that's like for production). - Trey

Andrzej Krzemienski

19 Mar 19 Mar

10:17 p.m.

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 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

Stephan Menzel

20 Mar 20 Mar

6:41 a.m.

Good Morning all, On Tue, Mar 19, 2019 at 11:18 PM Andrzej Krzemienski via Boost < boost@lists.boost.org> wrote:

...

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.

I just had a look and I think it's much better this way. Thank for for your constructive way of responding to my criticism. Cheers, Stephan

Paul A. Bristow

9:38 a.m.

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Stephan Menzel via Boost Sent: 20 March 2019 06:41 To: boost@lists.boost.org Cc: Stephan Menzel Subject: Re: [boost] usage of auto in tutorials

Good Morning all,

On Tue, Mar 19, 2019 at 11:18 PM Andrzej Krzemienski via Boost < boost@lists.boost.org> wrote:

...
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.

I just had a look and I think it's much better this way.

+1 :-) Paul

Olaf van der Spek

22 Mar 22 Mar

3:18 p.m.

On Tue, Mar 19, 2019 at 11:26 AM Andrzej Krzemienski via Boost wrote:

...

...
if (auto rslt = read_data_from_file("config.cfg"))

Is rslt short for result? Why not just use result? Greetings, Olaf

degski

3:31 p.m.

On Fri, 22 Mar 2019 at 17:18, Olaf van der Spek via Boost < boost@lists.boost.org> wrote:

...

...
...
if (auto rslt = read_data_from_file("config.cfg"))

Is rslt short for result? Why not just use result?

As the scope is by definition limited, I would opt for r [the smaller the scope the shorter the variable names]. degski -- *"Big boys don't cry" - **Eric Stewart, Graham Gouldman*

2076

Age (days ago)

2079

Last active (days ago)

List overview

Download

17 comments

10 participants

participants (10)

Andrzej Krzemienski
degski
Gavin Lambert
Joseph Van Riper
Mike
mike.dev＠gmx.de
Olaf van der Spek
Paul A. Bristow
Robert Ramey
Stephan Menzel