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

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #9 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/8769ea9e46154e1bbbd52ebca4ebf0a2ef20f8ef
Fix issue 18790 - Add ability for char[] and wchar[] to be output ranges.

--

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

[d-bugmail--- via Digitalmars-d-bugs]

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

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

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #8 from Steven Schveighoffer  ---
(In reply to Jonathan M Davis from comment #7)
> And if
> we can make the changes for output ranges without breaking any existing
> code, then we definitely should.

The only place where I see it may break code is that people have implemented
specialized versions of functions that work with char[] arrays since they are
not output ranges. This is going to create ambiguity errors, since you could
call both functions with a char[] now. I had to deal with this in phobos in a
couple places when creating this PR. In one case, the char[] version was
returning a DIFFERENT result type, so I couldn't just remove the char[]
version. There, I used template constraints to differentiate, no big deal.

In the second case, it's a bit more complex. When we are translating from one
character type to another, suddenly the put function loses its nothrow status.
For those who are handling the translation directly, and are assuming simple
transcoding (i.e. you know it's only ascii), their "workaround" function is
bound to be nothrow, meaning you can't use put directly.

In practice, I'm not sure how much code this will affect. I also don't know how
to do this through a deprecation.

--

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

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #7 from Jonathan M Davis  ---
(In reply to hsteoh from comment #4)
> Given that std.range.put goes out of its way to support putting single
> elements, multiple elements, and in some cases even dchars into strings, I'm
> shocked that putting dchar into char[] doesn't work. This needs to be made
> to work.

I think that what it comes down to is that because of the whole auto-decoding
fiasco, when Andrei originally did the work on output ranges, he made it so
that char[] and wchar[] were not output ranges for all of the reasons that they
weren't input ranges. However, with the improvements to put over the years, it
becomes increasingly silly for it to not work. And if we can make the changes
for output ranges without breaking any existing code, then we definitely
should.

--

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

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #6 from Steven Schveighoffer  ---
PR: https://github.com/dlang/phobos/pull/6471

--

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

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #5 from Steven Schveighoffer  ---
(In reply to Jonathan M Davis from comment #1)
> Because char[] isn't an output range at all. isOutputRange!(char[], char) is
> false.

Something to consider: isOutputRange!(char[], char) is false because
put(char[], char) doesn't compile.

So it's not a good explanation as to why put doesn't work. We can make put
work, and then isOutputRange will be true. Fun fact: put has NO template
constraints. Because it IS the source of the template constraints.

This is something so arbitrary, and I'm working on the code now to get it to
work, there are some really self-defeating reasons why this isn't working. This
should be a no brainer. The reasons for char[] not being an input range of char
don't translate to output ranges.

--

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

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #4 from hst...@quickfur.ath.cx ---
Given that std.range.put goes out of its way to support putting single
elements, multiple elements, and in some cases even dchars into strings, I'm
shocked that putting dchar into char[] doesn't work. This needs to be made to
work.

--

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

[d-bugmail--- via Digitalmars-d-bugs]

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

hst...@quickfur.ath.cx changed:

   What|Removed |Added

 CC||hst...@quickfur.ath.cx

--

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

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #3 from Steven Schveighoffer  ---
(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!

--

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

[d-bugmail--- via Digitalmars-d-bugs]

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

Nicholas Wilson  changed:

   What|Removed |Added

 CC||iamthewilsona...@hotmail.co
   ||m

--- Comment #2 from Nicholas Wilson  ---
dupe of https://issues.dlang.org/show_bug.cgi?id=18472 (see comment 10).

@JMDavies the problem is not that you can't `put(buf, "hello");`
but that formattedWrite does not force that to happen. Irrespective of the
intricacies of unicode and auto decoding 
---
char[] buf = new char[100];
buf.formattedWrite("This is a number: %s", 5); // Error cannot put a
const(char)[] into a char[]
---

should work.

--

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

[d-bugmail--- via Digitalmars-d-bugs]

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

Jonathan M Davis  changed:

   What|Removed |Added

 CC||issues.dl...@jmdavisprog.co
   ||m
   Severity|normal  |enhancement

--- Comment #1 from Jonathan M Davis  ---
(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.

> The answer to my question is (as usual) auto-decoding. ugh.

Yes. And I don't know what the solution to that is, not without actually
getting rid of autodecoding, and I don't see how we can do that without being
willing to silently break a lot of code or doing something like make it so that
strings aren't ranges anymore (at least temporarily), both of which would be
_really_ disruptive.

> 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. 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.

--