On Friday, September 27, 2024 2:13:45 PM MDT thinkunix via Digitalmars-d-learn wrote: > monkyyy via Digitalmars-d-learn wrote: > > On Friday, 27 September 2024 at 04:23:32 UTC, thinkunix wrote: > >> What about using 'auto' as the return type? > >> I tried it and it seemed to work OK. > >> > >> Wondering if there are any good reasons to use auto, > >> or bad reasons why not to use auto here? > > > > You have started a style debate that will last a week, great work > > That was not my intent. It was an honest question. I'm here to learn > and not looking to start debates or for attitude. > > I've seen a lot of "use auto everywhere" especially in C++ and was > wondering where the D community stands on it's use. Is it generally > favored or not? > > Personally, I think auto makes understanding code harder for humans. > But in this example, it seemed like auto was a good fit.
Well, I don't think that auto is a particularly controversial topic among D programmers, but there's no question that in at least some cases, it becomes a question of preference and style. auto is used heavily in D, and for some kinds of code, it has to be. In particular, range-based code routinely returns "Voldemort" types (types which you can't name) from a function. You care that it's a range (so that needs to be clear from the documentation), but you're not supposed to know or care what the actual type is. Before we had that, the signatures for a lot of range-based functions (e.g. most of std.algorithm) were actually pretty terrible to read and understand, because the explicit types were so long and messy (since it's very common for ranges to wrap one another, and they're usually templated). In a lot of those situations, you really only care about the API of the type and not what the exact type is. So, auto simplifies the code considerably and makes it easier to understand. auto is also pretty critical in generic code in general, because it allows you to not worry about the exact type you're dealing with. You just need to worry about which kinds of operations work with that particular type. So, variables get declared as auto all the time in typical D code. A lot of D programmers will only use the type explicitly with variables if they want to force a particular type or if they think that it makes that code easier to understand. auto can also make code more maintainable in that when refactoring code, the type will update automatically, so if it changes, you don't have to change it all over the place. On the flip side though, it does make it harder to know what types you're dealing with, which can sometimes make it harder to read and maintain code. So, when auto isn't actually needed, there's always going to be some debate about whether it's better to use auto or not, and that's subjective enough that you're really going to have to decide on your own what works for you. Also, for better or worse, because the function has to be compiled to determine the actual return type (so it won't work with function prototypes like in .di file), function attributes are inferred for auto return functions just like they are for templated functions, so some D programmers will make functions auto just to get the attribute inference. I would guess that as a general rule, most folks prefer explicit types in function signatures where auto isn't needed simply because it's self-documenting at that point. So, I would think that most D programmers would use an explicit type with the function being discussed in this thread, but auto will certainly work just fine. Without any explicit casts within the function, because doing math on char or ubyte results in int, the result is going to be int (as opposed to uint like in the original post). So, if that works for what the function is intended for, and the documentation is clear about what's being returned, then it's not a problem. However, in this particular case, it's arguably better to return ubyte than int or uint. That's because the result will always fit within a ubyte, and if you don't return a ubyte, the caller is going to have to cast to ubyte to do something like assign the value to a ubyte. So, simply returning auto as-is arguably isn't desirable. That being said, you can still use auto if you want to. Because the math results in int, casts to ubyte will be required regardless of whether the return type in the signature is ubyte or auto, but you could choose to use auto and have the result be ubyte thanks to the casts. Ultimately though, I would argue that in this case, auto just makes the code harder to understand. The documentation can easily say that the return type is ubyte in spite of it saying auto, but it's just as easy to type ubyte, and then the return type is immediately obvious instead of requiring additional documentation just to say what's being returned. So, while auto is used quite heavily in D code, I wouldn't expect many folks to choose to use auto for this particular function. - Jonathan M Davis
