On 03/26/2013 12:24 PM, Vladimir Panteleev wrote:
> On Tuesday, 26 March 2013 at 08:15:05 UTC, Timon Gehr wrote:
>> On 03/26/2013 03:21 AM, Vladimir Panteleev wrote:
>>> ...
>>>
>>> I use this feature in the same way that anyone uses a nullable type.
>>> It's the same distinction between a pointer to struct that is null, or
>>> that is pointing to an instance containing the struct's .init. It's the
>>> same distinction between a value type T and the benefits of Nullable!T.
>>> "null" is usually used to indicate the absence of a value, as opposed to
>>> an empty value.
>>>
>>
>> It is not the same distinction. It is not like that for dynamic arrays!
>>
>> void main(){ assert(null is []); }
>
> [] (the literal) has .ptr as null. That may or may not be a bug.

It is simply left unspecified. Hence, relying on a distinction between null and empty arrays is extremely brittle.

> To
> create a non-null empty array, you have to use something like (new
> uint[1])[0..0].

Sure, therefore [] is what will be used. Also, it does not always work.

auto x = { return (new uint[1])[0..0]; }();
void main(){ assert(x is null); }

> The "" literal does not have this problem.
>

Indeed, because it is guaranteed to be zero-terminated.

>>> Although I can see how this can trip up new users of D, personally I
>>> prefer things to be just the way they are now. That said, I wouldn't be
>>> against forcing one to write "s is null", if the consensus was that this
>>> would improve D.
>>
>> "s.ptr is null", actually
>
> The distinction being the case with a non-empty slice starting at
> address 0?

Yes. I think the conversion to bool is a leftover from when arrays implicitly decayed to pointers.

On 03/25/2013 06:11 PM, bearophile wrote:
> Timon Gehr:
>
>> Also, IMO null arrays should either be removed or [] should be
>> guaranteed to be non-null.
>
> This is a separated topic.

Not at all. It is very closely related.

> ...

On Tuesday, 26 March 2013 at 13:12:42 UTC, Timon Gehr wrote:
> It is simply left unspecified. Hence, relying on a distinction between null and empty arrays is extremely brittle.

I think calling it "extremely brittle" based on that [] is UD is an exaggeration. As I've stated, I maintain a nontrivial program which works with non-null empty strings and arrays, and rarely encountered difficulties.

>> To
>> create a non-null empty array, you have to use something like (new
>> uint[1])[0..0].
>
> Sure, therefore [] is what will be used. Also, it does not always work.
>
> auto x = { return (new uint[1])[0..0]; }();
> void main(){ assert(x is null); }

That looks like a CTFE bug. The same thing doesn't happen with strings and "".

>> The distinction being the case with a non-empty slice starting at
>> address 0?
>
> Yes. I think the conversion to bool is a leftover from when arrays implicitly decayed to pointers.

When would an array with null .ptr and non-zero length make sense? Do we want to care about such cases? We could simply state that slicing NULL is undefined behavior.

Vladimir Panteleev:

> We could simply state that slicing NULL is undefined behavior.

Undefined behaviors are bad.

Bye,
bearophile

"bearophile" <bearophileHUGS@lycos.com> wrote in message news:fqjmqdhpenxnfadxwgbx@forum.dlang.org...
> Daniel Murphy:
>
>> I am in favour of deprecating/removing this, then bringing it back so
>> that
>> if (arr)
>> is the same as
>> if (arr.length)
>
> That was my original idea :-) And it seems a nice idea.
>
> But turning something into a deprecation and later error is useful because it doesn't introduce bugs. While if you later assign it some other semantics, old D code will behave differently (despite it's probably potentially buggy code in the first place).
>
> So it's a matter of how much you want to break old D code.
>
> Bye,
> bearophile

The deprecation process is long and slow, so when it finally finishes the error stage we can evaluate how much legacy code we risk breaking.  Even if we never bring in the new meaning removing it will improve the language.

"Steven Schveighoffer" <schveiguy@yahoo.com> wrote in message news:op.wuibbpkbeav7ka@stevens-macbook-pro.local...
>
> I would favor just changing the behavior.  The existing behavior is most often a bug when it is used, because quite often arrays are null (that is the default value), and quite often, people THINK they are checking if the array is empty instead of if the pointer is null.  Because most empty arrays are null, and null arrays have zero length, their tests do not expose this bug.  It's actually very difficult to generate a non-null empty array for testing. [] does not work, it returns a null array!
>
> Only in rare cases do people actually want to check for null, and in most people's code it is an error when a non-null but empty array is checked with if(arr).  If people are interested in the pointer, they usually check if(arr.ptr) or if(arr !is null).
>
> I would posit that for every knowledgeable person who uses this "shortcut" to check for null, 100 people use it expecting it to be measuring the array length.
>
> If we go through a deprecation cycle, it makes people who do if(arr) for length have to change there code to if(arr.length) then back to if(arr) once the deprecation is over.  The switch to if(arr.length) will be simple, the compiler will show all the places if(arr) is used, but the switch back will be more difficult since if(arr.length) will not be deprecated.
>

There is no need to ever switch the code back.

> What about a switch that identifies all places where if(arr) is done? Then people who use if(arr) for testing if(arr.ptr) can find and fix their cases.  Or even a separate tool to do that.
>
> -Steve

I think the deprecation process is a better option than a switch, because it forces code to be fixed and gives people time to do so.  The less code we silently break the higher chance this has of Walter-approval.

On 3/26/13 10:07 AM, bearophile wrote:
> Vladimir Panteleev:
>
>> We could simply state that slicing NULL is undefined behavior.
>
> Undefined behaviors are bad.
>
> Bye,
> bearophile

Without -noboundscheck, which is opt-in, there is no undefined behavior.

Andrei

On Tuesday, March 26, 2013 12:24:56 Vladimir Panteleev wrote:
> [] (the literal) has .ptr as null. That may or may not be a bug.

As I understand it, it's very much on purpose. It avoids a needless memory allocation.

- Jonathan M Davis

On Tuesday, 26 March 2013 at 17:32:12 UTC, Jonathan M Davis wrote:
> On Tuesday, March 26, 2013 12:24:56 Vladimir Panteleev wrote:
>> [] (the literal) has .ptr as null. That may or may not be a bug.
>
> As I understand it, it's very much on purpose. It avoids a needless memory
> allocation.

In the same way that "" allocates memory?

[] can be an empty slice of *anything*, but it might as well be a 0-length constant in the data segment, similar to "".

On Tue, 26 Mar 2013 13:32:02 -0400, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Tuesday, March 26, 2013 12:24:56 Vladimir Panteleev wrote:
>> [] (the literal) has .ptr as null. That may or may not be a bug.
>
> As I understand it, it's very much on purpose. It avoids a needless memory
> allocation.

That is correct.  Since null and non-null-but-empty arrays are essentially equivalent, it would be wasteful to allocate a new block for 0 bytes.  Same as if you did new T[0].

-Steve