http://d.puremagic.com/issues/show_bug.cgi?id=8384



--- Comment #10 from Jonathan M Davis <jmdavisProg@gmx.com> 2012-08-15 13:35:28 PDT ---
char* acts identically to the other pointer types, and I fully believe that it should stay that way. We've pretty much removed all of the D features which involved either treating a string as char* or a char* as a string (including disallowing implicit conversion of string to const char*). The _only_ feature that the language has which supports that is the fact that string literals have a null character one past their end and will implicitly convert to const char*.

It would be a huge mistake IMHO to support doing _anything_ with character pointers which treats them as strings without requiring an explicit conversion of some kind. Anyone who continues to think of char* as being a string in D is just asking for trouble. They need to learn to use strings correctly.

If you really want to use char* as a string in functions like format or writeln, then simply either use to!string or ptr[0 .. strln(ptr)].

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=8384



--- Comment #11 from Vladimir Panteleev <thecybershadow@gmail.com> 2012-08-15 13:48:30 PDT ---
Sorry, I don't think that your categorical point of view is constructive. As long as D will interface with C libraries and programs, people will continue to attempt to use C strings together or in place of D strings, and issues like the above will continue to appear.

How often would a typical D user want to print / format the address of a character, versus the null-terminated string at that address?

> It would be a huge mistake IMHO to support doing _anything_ with character pointers which treats them as strings without requiring an explicit conversion of some kind.

Why would it be a mistake? What exactly do we lose by allowing writeln/format to understand C strings?

> Anyone who continues to think of char* as being a string in D is just asking for trouble.

What kind of trouble?

> They need to learn to use strings correctly.

D printing an address when text was expected will sooner generate a "D sucks" reaction than a "Oops, I need to learn to use strings correctly" one.

> If you really want to use char* as a string in functions like format or
writeln, then simply either use to!string or ptr[0 .. strln(ptr)].

That's not really simple, considering some spots where that (verbose) modification needs to be made would be discovered only late at runtime, and even then the actual problem is not obvious to identify (as seen in the SO question above).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=8384



--- Comment #12 from Vladimir Panteleev <thecybershadow@gmail.com> 2012-08-15 13:56:00 PDT ---
I would like to stress out a point that I hope could clear up my view of the logic that writeln/format should use.

Printing/formatting memory addresses is extremely rarely useful!

Except for some dirty debugging, I can't imagine a case where the user expects that passing a pointer to something to format would yield the hex representation of that address.

I believe that printing a pointer as a hex address should be the fallback, last-resort behavior, if there is no better representation for the said type. (This also allows discussion of calling toString() on struct pointers.)

For the rare case that the user intends to actually print a pointer, this is easily accomplished by a cast to size_t and using the appropriate hex format specifier.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=8384



--- Comment #13 from Jonathan M Davis <jmdavisProg@gmx.com> 2012-08-15 13:57:15 PDT ---
Anyone who does not understand that char* is _not_ a string will continue to
make mistakes like trying to concatenate a char* to a string (
http://stackoverflow.com/questions/11914070/why-can-i-not-concatenate-a-constchar-to-a-string-in-d
) or try and pass string directly to a C function. They will constantly run
into problems when dealing with strings. char* is _not_ a string and should not
be treated as such. Treating it as a string with something like writeln will
just help further the misconception that char* is a string and hinder people
learning and using D. D programmers need to understand the difference between
char* and string. char* should _not_ be treated as special, because it's not.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=8384



--- Comment #14 from Vladimir Panteleev <thecybershadow@gmail.com> 2012-08-15 14:01:42 PDT ---
First of all, you are conflating ignorance between the two string types with my arguments. Users who are aware that D has its own way of handling strings are still open to making frustrating mistakes.

Second, getting unexpected output is not a good way to teach people about this. Hence my earlier proposal to make writeln/format REJECT char pointer types, on the basis that the user's intention is ambiguous (I don't think so personally, but obviously that's just my opinion).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=8384



--- Comment #15 from Jonathan M Davis <jmdavisProg@gmx.com> 2012-08-15 14:06:49 PDT ---
I'm saying that we shouldn't treat char* differently from int* just because some newbies expect char* to act like a string. And if you know D, then you know that char* is _not_ a string, and I don't see how you could expect it to be treated as one. Either making char* act like a string or disallowing printing it would make it act differently from other pointer types just to appease the folks who mistakingly think that char* is a string.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=8384



--- Comment #16 from Vladimir Panteleev <thecybershadow@gmail.com> 2012-08-15 14:08:44 PDT ---
Well, then how about removing the pointer-printing feature entirely, and issue a compile-time error on all pointer types?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=8384



--- Comment #17 from Vladimir Panteleev <thecybershadow@gmail.com> 2012-08-15 14:12:50 PDT ---
> And if you know D, then you know that char* is _not_ a string, and I don't see how you could expect it to be treated as one.

I don't think this argument is valid, because it assumes that all D users are always aware of the types they pass to writeln/format. In the SO case, the argument is a function result, and the function's return type is not explicitly written in the user's code.

People often expect the compiler to shout at them if they try to pass incompatible types to a function. writeln/format accept char pointers, but ultimately do something with them that in 99% of cases is simply not useful, and put the user in search of their mistake all across the data flow.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=8384


Adam D. Ruppe <destructionator@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |destructionator@gmail.com


--- Comment #18 from Adam D. Ruppe <destructionator@gmail.com> 2012-08-15 14:34:54 PDT ---
I think rejecting might be the best option because if you treat it as a string, what if it doesn't have a 0 terminator? That could easily happen if you pass it a pointer to a D string.

I don't think that is technically un-@safe, but it could be a problem anyway to get an unexpected crash because of it. At least with to!string(char*) you might think about it for a minute and avoid the problem.


So on one hand, I think it should just work, but on the other hand the compile time error might be the most sane.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=8384



--- Comment #19 from Jonathan M Davis <jmdavisProg@gmx.com> 2012-08-15 14:40:14 PDT ---
> Well, then how about removing the pointer-printing feature entirely, and issue
a compile-time error on all pointer types?

So, you're suggesting that we remove a useful feature because newbies coming from C/C++ keep mistakingly thinking that char* is a string?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------