On Thursday, 19 November 2015 at 08:30:54 UTC, Jonathan M Davis wrote:
> On Wednesday, November 18, 2015 22:15:19 anonymous via Digitalmars-d-learn wrote:
>> [...]
>
> Exactly. T[] _is_ a dynamic array. Steven's otherwise wonderful article on arrays in D ( http://dlang.org/d-array-article.html ) made the mistake of calling the buffer that T[] points to on the GC heap (assuming that even does point to the GC heap) the dynamic array. And per the language spec, that's not true at all.
>
> [...]

I mentioned this because it's bit of an error trap, that I fell into.

char[] == null
vs
char[] is null

Is there any good use for char[] == null ? If not, a warning might be helpful.

On Wednesday, 18 November 2015 at 20:57:08 UTC, Spacen Jasset wrote:
> Should this be allowed ?

IMHO no.

It's better to use `.length` to test if an array is empty. Why ? Because the day you'll have a function whose parameter is a pointer to an array, comparing to null will become completly confusing:

---
void whyPeopleShouldUseLength(char[]* buffptr)
{
    if (buffptr != null && buffptr.length > 0) {}
}
---

Here you really have to test if the variable is assigned, it's not a shortcut to test the internal buffptr `.ptr` member.

I prefer

import std.array;
if(!arr.empty) {}

On Thursday, 19 November 2015 at 06:57:20 UTC, Jack Applegame wrote:
> Really? http://dpaste.dzfl.pl/b11346e8e341

Sorry, I said the exact opposite of what I meant to say. The `assert(a == null)` *is* triggered because the expression `a == null` fails, even though a.length == 0. You should not use `a == null` to check if an array is empty. Always use a.length == 0.

On Thursday, 19 November 2015 at 13:49:18 UTC, Meta wrote:
> On Thursday, 19 November 2015 at 06:57:20 UTC, Jack Applegame wrote:
>> Really? http://dpaste.dzfl.pl/b11346e8e341
>
> Sorry, I said the exact opposite of what I meant to say. The `assert(a == null)` *is* triggered because the expression `a == null` fails, even though a.length == 0. You should not use `a == null` to check if an array is empty. Always use a.length == 0.

Actually, no it's not. Never mind.

On Thu, 19 Nov 2015 07:28:28 +0100, anonymous wrote:

> On 19.11.2015 06:18, Chris Wright wrote:
>> Just for fun, is an array ever not equal to itself?
> 
> Yes, when it contains an element that's not equal to itself, e.g. NaN.

Exactly.

If NaN-like cases didn't exist, TypeInfo_Array could have an optimization: if the pointers and lengths of its inputs were both equal, the arrays are equal. But adding this optimization would result in problematic behavior. Specifically:

auto a = [float.nan];
assert(a == a);      // passes under proposed optimization, fails now
assert(a == a.dup);  // fails under proposed optimization, fails now

On 11/19/15 3:30 AM, Jonathan M Davis via Digitalmars-d-learn wrote:
> On Wednesday, November 18, 2015 22:15:19 anonymous via Digitalmars-d-learn wrote:
>> On 18.11.2015 22:02, rsw0x wrote:
>>> slices aren't arrays
>>> http://dlang.org/d-array-article.html
>>
>> The language reference/specification [1] uses the term "dynamic array"
>> for T[] types. Let's not enforce a slang that's different from that.
>>
>>
>> [1] http://dlang.org/arrays.html
>
> Exactly. T[] _is_ a dynamic array. Steven's otherwise wonderful article on
> arrays in D ( http://dlang.org/d-array-article.html ) made the mistake of
> calling the buffer that T[] points to on the GC heap (assuming that even
> does point to the GC heap) the dynamic array. And per the language spec,
> that's not true at all.

It was not a mistake :) It's how I still think of it. The spec is confusing, and my terminology, IMO, is a much more consistent (and accurate) way to think of it.

-Steve

On 11/19/15 5:04 AM, Spacen Jasset wrote:
> On Thursday, 19 November 2015 at 08:30:54 UTC, Jonathan M Davis wrote:
>> On Wednesday, November 18, 2015 22:15:19 anonymous via
>> Digitalmars-d-learn wrote:
>>> [...]
>>
>> Exactly. T[] _is_ a dynamic array. Steven's otherwise wonderful
>> article on arrays in D ( http://dlang.org/d-array-article.html ) made
>> the mistake of calling the buffer that T[] points to on the GC heap
>> (assuming that even does point to the GC heap) the dynamic array. And
>> per the language spec, that's not true at all.
>>
>> [...]
>
> I mentioned this because it's bit of an error trap, that I fell into.
>
> char[] == null
> vs
> char[] is null
>
> Is there any good use for char[] == null ? If not, a warning might be
> helpful.

Of course, if you are comparing something to an empty array, null is an effective literal to create one.

-Steve

On Thursday, 19 November 2015 at 10:04:37 UTC, Spacen Jasset wrote:
> char[] == null
> vs
> char[] is null
>
> Is there any good use for char[] == null ? If not, a warning might be helpful.

Actually char[] == null is a more usable one.

On Thursday, 19 November 2015 at 15:36:44 UTC, Steven Schveighoffer wrote:
> On 11/19/15 3:30 AM, Jonathan M Davis via Digitalmars-d-learn wrote:
>> On Wednesday, November 18, 2015 22:15:19 anonymous via Digitalmars-d-learn wrote:
>>> On 18.11.2015 22:02, rsw0x wrote:
>>>> slices aren't arrays
>>>> http://dlang.org/d-array-article.html
>>>
>>> The language reference/specification [1] uses the term "dynamic array"
>>> for T[] types. Let's not enforce a slang that's different from that.
>>>
>>>
>>> [1] http://dlang.org/arrays.html
>>
>> Exactly. T[] _is_ a dynamic array. Steven's otherwise wonderful article on
>> arrays in D ( http://dlang.org/d-array-article.html ) made the mistake of
>> calling the buffer that T[] points to on the GC heap (assuming that even
>> does point to the GC heap) the dynamic array. And per the language spec,
>> that's not true at all.
>
> It was not a mistake :) It's how I still think of it. The spec is confusing, and my terminology, IMO, is a much more consistent (and accurate) way to think of it.
>
> -Steve

Why formal definition of dynamic array caused confusion and is inconsistent? It is well consistent with static array and other aggregate types notions.

Consider this:

int *x = new int; // this is 'int type' ans it is 'dynamic'
int y;
int *a = &y;            // and this is not 'int type'

The problem is treating chunk of heap memory as some kind of type (dynamic in this case). Type of object determines an interface of interacting with object while storage determines memory location and possibly duration of lifetime. It is possible to have object of any type to be allocated on different storages - for example, slice does not necessarily points to dynamic array (in your terms). C and C++ established a long tradition of such standard notions as object, lifetime, storage and type. From system language perspective calling memory a type (in other words, type of object depends on where it was allocated) does not make much sense.