https://issues.dlang.org/show_bug.cgi?id=18790
--- Comment #3 from Steven Schveighoffer <schvei...@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! --