On Monday, 20 April 2015 at 18:01:20 UTC, Jonathan M Davis wrote:
> An array in C is a pointer, not a struct.

True. I only question the claim that they don't care about such things.
Also difference between pointer and reference types seems to be no problem for STL string. If it wasn't designed by C programmers, then by whom?

> So, the obvious thing for a C programmer when they see
>
> if(arr)
>
> would be to think that it was equivalent to
>
> if(arr != NULL)

Don't you contradict yourself now?
arr!=null is equivalent to arr.length!=0

> D tries to avoid segfaulting for null arrays

In fact nothing like that ever happened. Bug 14436 exists because there was never any special treatment for null slices.

On Wednesday, April 22, 2015 10:19:01 Kagamin via Digitalmars-d wrote:
> On Monday, 20 April 2015 at 18:01:20 UTC, Jonathan M Davis wrote:
> > An array in C is a pointer, not a struct.
>
> True. I only question the claim that they don't care about such
> things.
> Also difference between pointer and reference types seems to be
> no problem for STL string. If it wasn't designed by C
> programmers, then by whom?
>
> > So, the obvious thing for a C programmer when they see
> >
> > if(arr)
> >
> > would be to think that it was equivalent to
> >
> > if(arr != NULL)
>
> Don't you contradict yourself now?
> arr!=null is equivalent to arr.length!=0

Um. No. In C, arr != NULL, and arr.length are completely different. If you wanted to check the length, you'd either have to have a separate length variable or being operating on a zero-terminated string and use strlen. And arr != NULL isn't legal D, so I would have thought that it would be clear that I meant C code with that line.

> > D tries to avoid segfaulting for null arrays
>
> In fact nothing like that ever happened. Bug 14436 exists because there was never any special treatment for null slices.

D arrays were designed in a way that they avoid segfaults; otherwise an empty array and a null array would not be considered equal, and doing stuff like trying to append to a null array would segfault. You have to work at it to get a segfault with D arrays. That doesn't mean that the optimizer does the best job (as evidenced by 14436), but D arrays are quite clearly designed in a manner that avoids segfaults and conflates null with empty as a result.

- Jonathan M Davis

Interesting trivia, I even found this bug in the documentation of the
first dmd release http://downloads.dlang.org/releases/0.x/0.100/dmd.100.zip.


Checking For Empty Strings

C++ strings use a function to determine if a string is empty:
	string str;
	if (str.empty())
		// string is empty
In D, an empty string is just null:
	char[] str;
	if (!str)
		// string is empty


Apparently it was later fixed to if (!str.length)
http://www.digitalmars.com/d/1.0/cppstrings.html.

On Wednesday, 22 April 2015 at 10:36:04 UTC, Jonathan M Davis wrote:
>> > So, the obvious thing for a C programmer when they see
>> >
>> > if(arr)
>> >
>> > would be to think that it was equivalent to
>> >
>> > if(arr != NULL)
>>
>> Don't you contradict yourself now?
>> arr!=null is equivalent to arr.length!=0
>
> that I meant C code with that line.

If C programmers won't apply C intuition in D code, then there's no problem?

> D arrays were designed in a way that they avoid segfaults; otherwise an
> empty array and a null array would not be considered equal, and doing stuff
> like trying to append to a null array would segfault. You have to work at it
> to get a segfault with D arrays.

Hmm... if D arrays allow segfaults, that means, they don't avoid segfaults. Empty and null arrays are considered equal because the array comparison algorithm iterates over their contents and compares elements one by one, if the loop passes all elements successfully, then the slices are equal. The algorithm pays no attention to null slices and doesn't make any precautions against segfaults, it looks as if it assumes that slices are even non-empty.

> That doesn't mean that the optimizer does
> the best job (as evidenced by 14436), but D arrays are quite clearly
> designed in a manner that avoids segfaults and conflates null with empty as a result.

14436 is a direct consequence of absence of any special treatment of null slices, no special attention was ever paid to null slices, no avoidance of segfaults in any way ever existed in the code. That's a total misconception.

On 4/22/15 6:10 PM, Martin Nowak wrote:
> Interesting trivia, I even found this bug in the documentation of the
> first dmd release http://downloads.dlang.org/releases/0.x/0.100/dmd.100.zip.
>
>
> Checking For Empty Strings
>
> C++ strings use a function to determine if a string is empty:
> 	string str;
> 	if (str.empty())
> 		// string is empty
> In D, an empty string is just null:
> 	char[] str;
> 	if (!str)
> 		// string is empty
>
>
> Apparently it was later fixed to if (!str.length)
> http://www.digitalmars.com/d/1.0/cppstrings.html.
>

Ahh, if only we could go back in time and force Walter to fix the compiler instead of the docs ;)

-Steve

On Wednesday, 22 April 2015 at 10:36:04 UTC, Jonathan M Davis wrote:
> D arrays were designed in a way that they avoid segfaults; otherwise an
> empty array and a null array would not be considered equal, and doing stuff
> like trying to append to a null array would segfault. You have to work at it
> to get a segfault with D arrays. That doesn't mean that the optimizer does
> the best job (as evidenced by 14436), but D arrays are quite clearly
> designed in a manner that avoids segfaults and conflates null with empty as
> a result.
>
> - Jonathan M Davis

This is one of my favourite features of D. I've seen so many problems in Java where someone passes null instead of an ArrayList to a method and it throws a NullPointerException. I love that I can just use foreach on a null slice, or check its length, and not care if it's null most of the time. (But still check if it's null if I really, really care.)

FYI, Andrei and Walter are reversing this change barring any new evidence it's helpful to people. Please speak up if you disagree.

https://github.com/D-Programming-Language/dmd/pull/2885#issuecomment-97299912

-Steve

On 4/28/15 9:38 PM, Steven Schveighoffer wrote:
> FYI, Andrei and Walter are reversing this change barring any new
> evidence it's helpful to people. Please speak up if you disagree.
>
> https://github.com/D-Programming-Language/dmd/pull/2885#issuecomment-97299912

We shouldn't frame it as black and white. It has usefulness, it also has drawbacks. My thesis is the drawbacks overwhelm the usefulness. -- Andrei

On 4/29/15 1:14 AM, Andrei Alexandrescu wrote:
> On 4/28/15 9:38 PM, Steven Schveighoffer wrote:
>> FYI, Andrei and Walter are reversing this change barring any new
>> evidence it's helpful to people. Please speak up if you disagree.
>>
>> https://github.com/D-Programming-Language/dmd/pull/2885#issuecomment-97299912
>>
>
> We shouldn't frame it as black and white. It has usefulness, it also has
> drawbacks. My thesis is the drawbacks overwhelm the usefulness. -- Andrei
>

I'm not. This is an RFP to answer your call for more evidence.

-Steve

On 4/28/15 11:03 PM, Steven Schveighoffer wrote:
> On 4/29/15 1:14 AM, Andrei Alexandrescu wrote:
>> On 4/28/15 9:38 PM, Steven Schveighoffer wrote:
>>> FYI, Andrei and Walter are reversing this change barring any new
>>> evidence it's helpful to people. Please speak up if you disagree.
>>>
>>> https://github.com/D-Programming-Language/dmd/pull/2885#issuecomment-97299912
>>>
>>>
>>
>> We shouldn't frame it as black and white. It has usefulness, it also has
>> drawbacks. My thesis is the drawbacks overwhelm the usefulness. -- Andrei
>>
>
> I'm not. This is an RFP to answer your call for more evidence.

Ah, right. I misread, apologies. -- Andrei