Phobos examples and auto

Marco Leise Marco.Leise at gmx.de
Sun Nov 6 03:43:01 PST 2011


That's my cup of bike shedding!

Am 06.11.2011, 09:20 Uhr, schrieb Jonathan M Davis <jmdavisProg at gmx.com>:

> A few of the reasons are
>
> 1. Some functions (especially those in std.algorithm) return templated  
> types
> which you _don't_ want to have to type yourself or even worry about or  
> care
> what they are beyond the fact that they're a range. auto makes such  
> functions
> quite usable and useful whereas as they would be completely unreasonable
> otherwise. So, ranges in general definitely are used with auto.

No one disagrees on that auto must be used here.

> 2. With auto, if you change the type, you often don't have to change the  
> code.
> For instance, if you have a function which returns a particular type,  
> and you
> use auto, then if you change the type that it returns later and the new  
> type
> has same API (or close enough that it doesn't matter for your code),  
> then you
> don't have to change any of your code, whereas if you didn't use auto,  
> you
> would. So, auto tends to make refactoring much easier.

Ok, I cannot really comment on that. It also hides some information, which  
could make it more difficult for someone else looking at the code to  
identify the used types. Then range templates are somewhat well-known. You  
know that what you get out is still a range of the type that you put in.

> 3. Code tends to be more concise with auto. You avoid having to repeat  
> the
> type name on both sides of the assignment operator.

This is the ideal use case for auto and in DDOC it would not hide  
information. (Still I think it is a matter of personal taste and since I  
use to have a bad spelling I appreciate DDT to auto-complete method names,  
which doesn't currently work with auto ;) ).

It's not like we are discussing removing auto from the language specs.  
It's just that the documentation would benefit from explicit return types  
where they are proper types of their own, like TickDuration. I find it  
easier to comprehend how something works when I have less open questions  
to carry around while reading. Imagine the documentation of  
TickDuration.currAppTick() had an auto return type. Then the reader would  
have to look up in the source code if it returns a long or a TickDuration.  
That cannot be good.
On the other hand it could be that Steve would want that all occurrences  
of 'auto' are removed in the documentation. But I don't believe that.


More information about the Digitalmars-d mailing list