What's the bug in the following code:

```d
import std.digest.md;
import std.stdio;

pragma(inline, false) // just in case
string getHash()
{
    ubyte[16] hash = [1,2,3,4,5,6,6,78,8,8,7,7,6,3,2,3];
    string a = toHexString(hash);
    return a;
}

pragma(inline, false) // just in case
void destroystack()
{
    writeln("asd","asd","asd","asd","asd","asd");
}

void main()
{
    string a = getHash();
    destroystack();
    writeln(a);
}
```

Hint: when changing
```
    string a = toHexString(hash);
    return a;
```
to
```
    return toHexString(hash);
```
the compiler errors with:
`Error: escaping reference to stack allocated value returned by toHexString(hash)`.

So:
-  the documentation of toHexString says that the overloads returning a string return a GC allocated string
- the _implementation_ of `string toHexString(...)` does a `new char[16]`, so GC allocates.
- `string a = toHexString(hash);` calls `char[num*2] toHexString(...)` instead of `string toHexString(...)`.   OOPS.

https://issues.dlang.org/show_bug.cgi?id=16519

I don't know whether this is a compiler bug (choosing the wrong overload) or a Phobos bug (overloads don't work like that).
How are template overloads involving `string` and `char[constant]` return values supposed to work?

Still can't believe I am the first one to run into this, what am I doing wrong?

-Johan

On Wednesday, 21 September 2016 at 12:07:31 UTC, Johan Engelen wrote:
>     string a = toHexString(hash);

This is a pretty common pitfall (and IMO one of the most egregious design flaws in the language), I see it all the time.

toHexString, when given a static array, returns a static array, but the language allows you to implicitly slice that into a pointer (mistaken design in any case, doubly so since it a stack pointer)... and moreover it is implicitly cast to immutable!

So it will implicitly cast that char[x] to string in a LOT of places... and it is almost always wrong.

If you passed `hash[]` it should then do what you want... so arguably the implicit slice rule is confusing you here too, I'd LOVE to kill that rule entirely.

> I don't know whether this is a compiler bug (choosing the wrong overload) or a Phobos bug (overloads don't work like that).

It is neither, the compiler chose the right overload (remember, overloads are chosen based on the arguments alone, the type you specify for the variable holding the return value isn't a consideration there) and the implementation of each overload is correct.

But the horribly wrong implicit slice and cast rules make it do the totally wrong thing while looking fine at first glance.

On Wednesday, 21 September 2016 at 12:20:14 UTC, Adam D. Ruppe wrote:
> 
> It is neither, the compiler chose the right overload (remember, overloads are chosen based on the arguments alone, the type you specify for the variable holding the return value isn't a consideration there) and the implementation of each overload is correct.

Wouldn't something like this be possible?

`T toHexString(string toHexString(Order order = Order.increasing, LetterCase letterCase = LetterCase.upper, T)(.........) if (T == string)`

On Wednesday, 21 September 2016 at 12:20:14 UTC, Adam D. Ruppe wrote:
>
> This is a pretty common pitfall (and IMO one of the most egregious design flaws in the language), I see it all the time.

I write very little D code, so I guess it had to happen at some point then. Man, this is really bad :((

> toHexString, when given a static array, returns a static array, but the language allows you to implicitly slice that into a pointer (mistaken design in any case, doubly so since it a stack pointer)... and moreover it is implicitly cast to immutable!

Thanks for the explanation.
It should really be mentioned in the documentation of toHexString, with an actual example instead of a unittest.
The original code was doing:
```
    MD5 md5;
    md5.start();
    md5.put(cast(const(ubyte)[]) "some interesting data");
    auto hash = md5.finish();
    return toHexString!(LetterCase.lower)(hash);
```

I guess `ubyte[] hash = md5.finish();` would have fixed it too.

On Wednesday, 21 September 2016 at 12:29:54 UTC, Johan Engelen wrote:
> Wouldn't something like this be possible?
>
> `T toHexString(string toHexString(Order order = Order.increasing, LetterCase letterCase = LetterCase.upper, T)(.........) if (T == string)`

I'm not sure what that's supposed to be.... but in any case, you'd still need to specify T somewhere in the call, the variable you are assigning the result to never does anything with regard to overloads or template args.

On Wednesday, 21 September 2016 at 13:06:08 UTC, Adam D. Ruppe wrote:
> 
> the variable you are assigning the result to never does anything with regard to overloads or template args.

Gotcha, thanks.

On Wednesday, 21 September 2016 at 12:39:57 UTC, Johan Engelen wrote:
> It should really be mentioned in the documentation of toHexString, with an actual example instead of a unittest.

Do you use my dpldocs.info? I add such notes there from time to time:

http://dpldocs.info/experimental-docs/std.digest.digest.toHexString.1.html


> I guess `ubyte[] hash = md5.finish();` would have fixed it too.

Yes, though IMO that's still depending on the same language design flaw. I'd prefer to just explicitly pass `hash[]` to the function call so it is clear right there.