On Fri, 18 May 2012 11:05:21 -0400, Christophe Travert <travert@phare.normalesup.org> wrote:

> "Steven Schveighoffer" , dans le message (digitalmars.D:167556), a
>> toStringz can allocate a new block in order to ensure 0 gets added.  This
>> is ludicrous!
>>
>> You are trying to tell me that any time I want to call a C function with a
>> string literal, I have to first heap-allocate it, even though I *know*
>> it's safe.
>
> How about "mystring\0".ptr ?

AKA "mystring" :)

I'm sorry, I don't see the reason to require this.  All for the sake of making "" a null slice.  I find the net gain quite trivial.

-Steve

On Friday, May 18, 2012 11:18:46 Steven Schveighoffer wrote:
> On Fri, 18 May 2012 11:05:21 -0400, Christophe Travert
> 
> <travert@phare.normalesup.org> wrote:
> > "Steven Schveighoffer" , dans le message (digitalmars.D:167556), a
> > 
> >> toStringz can allocate a new block in order to ensure 0 gets added.
> >> This
> >> is ludicrous!
> >> 
> >> You are trying to tell me that any time I want to call a C function
> >> with a
> >> string literal, I have to first heap-allocate it, even though I *know*
> >> it's safe.
> > 
> > How about "mystring\0".ptr ?
> 
> AKA "mystring" :)
> 
> I'm sorry, I don't see the reason to require this. All for the sake of making "" a null slice. I find the net gain quite trivial.

And I find the net gain to be negative, since the fact that "" is non-null is _useful_.

- Jonathan M Davis

"Jonathan M Davis" , dans le message (digitalmars.D:167901), a écrit :
> On Friday, May 18, 2012 11:18:46 Steven Schveighoffer wrote:
>> On Fri, 18 May 2012 11:05:21 -0400, Christophe Travert
>> 
>> <travert@phare.normalesup.org> wrote:
>> > "Steven Schveighoffer" , dans le message (digitalmars.D:167556), a
>> > 
>> >> toStringz can allocate a new block in order to ensure 0 gets added.
>> >> This
>> >> is ludicrous!
>> >> 
>> >> You are trying to tell me that any time I want to call a C function
>> >> with a
>> >> string literal, I have to first heap-allocate it, even though I *know*
>> >> it's safe.
>> > 
>> > How about "mystring\0".ptr ?
>> 
>> AKA "mystring" :)
>> 
>> I'm sorry, I don't see the reason to require this. All for the sake of making "" a null slice. I find the net gain quite trivial.
> 
> And I find the net gain to be negative, since the fact that "" is non-null is _useful_.
> 
> - Jonathan M Davis

I'm not saying "" should point to null. I'm saying people claiming that they have to heap-allocate (via toStringz) each time they call a c-function are just wrong. I tend to accept the point that making strings automatically zero terminated for making calls to c-function easier is not such a good idea, but I have no problem with [] !is "". Empty strings should be tested with empty.

-- 
Christophe

Am Wed, 16 May 2012 09:18:38 -0400
schrieb "Steven Schveighoffer" <schveiguy@yahoo.com>:

> Regardless, we should fix if(!arr) to mean if(!arr.length).
> 
> -Steve

I'm still using 2.057 (GDC). My mental model of D tells me: A reference type's pointer is implicitly converted to bool, when used inside an if-expression.

These are equal statements for any reference type:

	if(reference_type is null)
	if(!(reference_type !is null))
	if(!reference_type)

As an example, I use the these semantics and they feel correct to me. Look at this example where a solution set is expressed as a long[]:

	long[] empty_solution = [];
	assert(empty_solution);     // the solution set is empty (a = a + 42)
	long[] no_solution = null;
	assert(!no_solution);       // a solution is not computable (a = a)

The shortest form is also the most basic one: Do we have a solution set at all?
Once I'm past the 'existence' check, I'd look at the length: if (solution.length == 1) ...
In other use cases you make no distinction between "is null" and "length == 0". For those it is ok to check "if (arr.length)", but I want to make you aware that both cases exist and I think the way it worked in 2.057 was consistent.

Now with 2.059 I have to turn a solution set into a structure with a flag like 'solved'. The language got less expressive here. If that's how it is going too stay then yes, "if(arr)" should really mean "if(arr.length)", because the only time it is not the same is when the language accidentally exposes the implementation detail that an empty string actually needs memory. :)

-- 
Marco

Am Tue, 15 May 2012 20:23:53 +0200
schrieb Timon Gehr <timon.gehr@gmx.ch>:

> 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