Per Nordlöw via Digitalmars-d-learn wrote:
> Should a function like
> 
> ```d
> uint parseHex(in char ch) pure nothrow @safe @nogc {
>      switch (ch) {
>      case '0': .. case '9':
>          return ch - '0';
>      case 'a': .. case 'f':
>          return 10 + ch - 'a';
>      case 'A': .. case 'F':
>          return 10 + ch - 'A';
>      default:
>          assert(0, "Non-hexadecimal character");
>      }
> }
> ```
> 
> instead return an ubyte?

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?

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

Auto is fantastic and everyone should use it more

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.

On Fri, Sep 27, 2024 at 04:13:45PM -0400, thinkunix via Digitalmars-d-learn wrote: [...]
> 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.

In idiomatic D, you'd use `auto` when either (1) you don't care what the type is, you just want whatever value you get to be shoved into a variable, or (2) you *shouldn't* care what the type is, because your code shouldn't be depending on it, e.g., when you're using Voldemort types std.algorithm-style.

The reason for (2) is that in UFCS chains, the only thing you really only care about is what kind of range it is that you're dealing with, and maybe the element type.  What exactly the container type is, is unimportant, and in fact, stating it explicitly is detrimental to maintenance because the library that gave you that type may change the concrete type in the future while retaining the same range and element type.  So by naming an explicit type for the range, you introduce a potential needless breakage in your code when you next upgrade the library.  Instead, use `auto` to let the compiler figure out what the concrete type is, as long as it conforms to the expected range semantics and has a compatible element type, your code will continue to work as before.

This applies not only to library upgrades, but also to code maintenance, e.g., if you decide to reshuffle the elements of a UFCS chain to fix a bug or introduce a new feature.  If explicit types were always used, every such change would entail finding out and updating the type of every component in the chain -- for long chains, this quickly becomes onerous and unmaintainable.  Instead, use `auto` to let the compiler figure it all out for you, and make your code independent of the concrete type so that you can simply move things around just by cutting and pasting, and you don't have to worry about updating every single referenced type.


T

-- 
How do you solve any equation?  Multiply both sides by zero.

On Thursday, September 26, 2024 12:53:12 AM MDT Per Nordlöw via Digitalmars-d- learn wrote:
> Should a function like
>
> ```d
> uint parseHex(in char ch) pure nothrow @safe @nogc {
>   switch (ch) {
>   case '0': .. case '9':
>       return ch - '0';
>   case 'a': .. case 'f':
>       return 10 + ch - 'a';
>   case 'A': .. case 'F':
>       return 10 + ch - 'A';
>   default:
>       assert(0, "Non-hexadecimal character");
>   }
> }
> ```
>
> instead return an ubyte?

I would argue that ubyte would be better, because it's guaranteed to fit into a ubyte, but if it returns uint, then anyone who wants to assign it to a ubyte will need to cast it, whereas you can just do the casts right here (which could mean a lot less casting if this function is used much). Not only that, but you'd be doing the casts in the code that controls the result, so if something ever changes that makes it so that the type needs to change (e.g. you make it operate on dchar instead of char), you won't end up with callers casting to ubyte when the result then doesn't actually fit into a ubyte - whereas if parseHex's function signature changes from returning ubyte to returning ushort or uint or whatnot, then the change would be caught at compile time with any code that assigned the result to a ubyte.

Now, I'm guessing that it wouldn't ever make sense to change this particular function in a way that the return type needed to change, and returning uint should ultimately work just fine, but I think that restricting the surface area where narrowing casts are likely to happen will ultimately reduce the risk of bugs, and I think that it's pretty clear that there will be less casting overall if the casting is done here instead of at the call site unless the function is barely ever used.

- Jonathan M Davis