Am Tue, 15 May 2012 20:23:53 +0200
schrieb Timon Gehr <[email protected]>:
> On 05/15/2012 10:39 AM, deadalnix wrote:
> > Le 14/05/2012 19:38, Alex Rønne Petersen a écrit :
> >> [...]
> >> That being said, dropping the null-termination rule when passing strings
> >> to non-const(char)* parameters/variables/etc would be sane enough (I
> >> think).
I thought the same.
> > This looks to me like a bad practice. C string and D string are
> > different beasts, and we have toStringz .
When we talk about literal strings they can be both.
void foo(const(char)*) will turn a string literal into a '\0'-terminated C
string.
void foo(string) will use D string (slices).
It is a special case for C interop. There may already be a few others in the
language.
> It is not. Claiming valid use cases are bad practice does not help the
> discussion. It is disrespectful and patronising.
Alex' use case of this feature:
void log(string text) {
printf(text);
}
made me think the same: "That's a bad idea...". This runs against a D
programmer's understanding of a string as a pointer and length without explicit
termination. If you just had this in mind:
printf("abc");
that looks kosher.
> > It is kind of dumb to create a WAT is the language because druntime dev
> > did mistakes.
Yes, let's have zero appended when literals are used as char* parameters.
I just greped druntime for [f]printf and except for one ternary operator and
one (tbuf.ptr, tbuf.length, ...) the format specifiers were all literals. No
concatenations and slicing (thank god ;) ) or lookups and storage in a string
before use. If these 759 printf statements reflect the general case, then there
should be no problem with the proposal. (The one use of the ternary operator
can probably be changed to an if-else.)
> The conclusion is based on a wrong premise therefore it is meaningless.
>
> > It have to be fixed.
>
> It can be fixed better by making (null !is []) hold instead of making
> ("" is null) hold.
It's easy. Revert to 2.057. I agree with you, but I'm ignorant to the reasons
behind the change. It could have meant an allocation for empty arrays (the way
it was implemented in 2.057) or that the GC cannot collect a large memory block
because a slice of length 0 is holding a reference to it.
--
Marco
