[Issue 18790] can't put a const(char)[] into a char[]

[d-bugmail at puremagic.com]

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

--- Comment #3 from Steven Schveighoffer <schveiguy at yahoo.com> ---
(In reply to Jonathan M Davis from comment #1)
> (In reply to Steven Schveighoffer from comment #0)
> > The most basic string output range is char[]. Why can't I put a string in
> > there?
> 
> Because char[] isn't an output range at all. isOutputRange!(char[], char) is
> false. No array of char or wchar is an output range, as annoying as that may
> be.

Well, actually, it's isOutputRange!(char[], dchar), and right it's not an
output range. But not because it can't be done. Even with decoding/encoding it
could be done. It just can't be done through the general 'assign-to-front'
option. It would have to be a special case inside the put function itself.

The issue I have is that I want to build a string on the stack that I can use
for example for looking up a value in an AA. I don't want to use Appender
because I'm trying to keep it on the stack.

I have figured out a workaround, I can use byCodeUnit to make it "work", but I
have to do some flips around the type to make it back to a char[].

> > At the very least, the message should be clearer (obviously, we can put a
> > string into a char[]!).
> 
> Well, actually, you _can't_ "put" string into a char[]. put doesn't work
> with char[]. So, it's perfectly accurate. However, it's also a terrible
> message, because all it's saying is that put doesn't compile with the given
> arguments, not why.

There's another factor: the term 'put' is also an english verb. I didn't even
notice that it's talking about put the function, I thought it was just telling
me in general something that's not possible that clearly is. Note that I first
saw the error when trying to use formattedWrite, so I wasn't even calling put.
In the bug report, though, I figured I would boil it down to the lowest level.

> It really should say something more like "char[] isn't
> an output range", and if there's a similar static assert for types that
> _are_ output ranges but don't accept the given type, then they should have a
> different message for that that makes it clear that the output range doesn't
> have a put method that accepts the given argument type, and
> std.range.primitives.put can't convert it for you.

That would have been a better, yet still frustrating, error message. But at
least I would know what the real problem is!

--