On 4/10/15 6:26 AM, Meta wrote:
> On Friday, 10 April 2015 at 12:42:47 UTC, Steven Schveighoffer wrote:
>> Plus, adding arr.empty into object is kind of redundant. The only
>> reason we have arr.empty is so that it becomes a range.
>>
>> -Steve
>
> I find it extremely annoying to have to import std.array (or whatever
> the correct module is) just to use .empty, .front and .popFront on
> arrays. IMO they should all be in object.d.

Yah, I was about to post the same. Range semantics are embedded in the language enough to warrant this.

Also empty should work for AAs.


Andrei

On Fri, 10 Apr 2015 23:47:19 +1000, Daniel Murphy wrote:

> "ketmar"  wrote in message news:mg8hda$2rs$12@digitalmars.com...
> 
> 
>> > I use arr.length when I'm working with arrays, and .empty when working with general ranges.  I generally prefer not to mix the two.
>>
>> isn't it a compiler task to track types? ranges can be empty, arrays can be empty. i can't see why one should remember that their emptiness if somehow different.
> 
> Nobody said you have to remember anything, it's a style choice.

ah, sorry, i thought that you mean "there is no sense to moving `.empty`, 'cause people should use `.length` for arrays". sorry.

On 4/10/15 10:53 AM, Andre Kostur wrote:
> On 2015-04-10 5:42 AM, Steven Schveighoffer wrote:
>>
>> empty is a negative. I'd prefer if(arr.length) instead of
>> if(!arr.empty), as the latter's a double-negative.
>
> Hmm.  I've never thought of empty as a negative.  For me empty says
> "This thing has the property/state of being empty", not "this thing has
> a corresponding length (or size) of not 0".  Thus if (!arr.empty) is
> only a single negative for me.  "This thing does not have the state of
> being empty."
>

empty means having nothing. In other words, if something is not empty, it doesn't have nothing in it.

It's the way I see it anyway. When I want to check for the presence of something, I don't want to say it by checking for the lack of nothing.

There, I'm confused now :)

-Steve

On 4/10/15 11:57 AM, Andrei Alexandrescu wrote:
> On 4/10/15 6:26 AM, Meta wrote:
>> On Friday, 10 April 2015 at 12:42:47 UTC, Steven Schveighoffer wrote:
>>> Plus, adding arr.empty into object is kind of redundant. The only
>>> reason we have arr.empty is so that it becomes a range.
>>>
>>> -Steve
>>
>> I find it extremely annoying to have to import std.array (or whatever
>> the correct module is) just to use .empty, .front and .popFront on
>> arrays. IMO they should all be in object.d.
>
> Yah, I was about to post the same. Range semantics are embedded in the
> language enough to warrant this.
>
> Also empty should work for AAs.

How should "abc".front work? Do you want to move unicode decoding of char and wchar arrays into object.d? Serious question, not rhetorical, because I'm not for or against it (except for the notion of changing things for the sake of changing them), I just want to point out what is required.

-Steve

On Friday, 10 April 2015 at 11:59:32 UTC, Kagamin wrote:
> On Friday, 10 April 2015 at 11:39:59 UTC, Vladimir Panteleev wrote:
>> https://github.com/D-Programming-Language/tools/pull/166/files
>> I don't know the code well enough to know if arr != null would be more appropriate.
>
> It's probably a nitpick, I like arr!=null expression a lot, but currently compiler generates a horrible code for it: ldc generates comparison with typeinfos, and dmd inlines whole memcmp among other things instead of converting it to just arr.length!=0.

gcc does what you want:

bool foo(int[] a)
{
  return a != null;
}

bool bar(int[] a)
{
  return a.length != 0;
}

bool example.foo(int[]):
	testq	%rdi, %rdi
	setne	%al
	ret
bool example.bar(int[]):
	testq	%rdi, %rdi
	setne	%al
	ret

On Friday, 10 April 2015 at 17:37:03 UTC, John Colvin wrote:
> On Friday, 10 April 2015 at 11:59:32 UTC, Kagamin wrote:
>> On Friday, 10 April 2015 at 11:39:59 UTC, Vladimir Panteleev wrote:
>>> https://github.com/D-Programming-Language/tools/pull/166/files
>>> I don't know the code well enough to know if arr != null would be more appropriate.
>>
>> It's probably a nitpick, I like arr!=null expression a lot, but currently compiler generates a horrible code for it: ldc generates comparison with typeinfos, and dmd inlines whole memcmp among other things instead of converting it to just arr.length!=0.
>
> gcc does what you want:
>
> bool foo(int[] a)
> {
>   return a != null;
> }
>
> bool bar(int[] a)
> {
>   return a.length != 0;
> }
>
> bool example.foo(int[]):
> 	testq	%rdi, %rdi
> 	setne	%al
> 	ret
> bool example.bar(int[]):
> 	testq	%rdi, %rdi
> 	setne	%al
> 	ret

Whoops, that should be gdc, not gcc

On Friday, 10 April 2015 at 10:09:18 UTC, jkpl wrote:
> Then, imagine that the syntactic shortcut is accepted, this would lead to the following confusion:
> ---
> char[] * arr;
> if(arr)
> ---
> Here the test is really about the array being null or not.

`arr` is a pointer, not an array. I don't understand what you're arguing here.

>
> It's like in the topic from yesterday:
>
> ---
> void a(uint p, string a = null){}
> ---
>
> Totally wrong, the guy should write:
>
> ---
> void a(uint p, string a = ""){}
> ---
>

I don't know what that topic was about, but there is nothing obviously wrong with either version. The language mostly treats both the same way:

    string nullstr = null;
    assert(nullstr == "");
    assert(nullstr.length == 0);

The only difference is that "" has a non-null address:

    assert(!nullstr.ptr);
    assert("".ptr);

OTOH, maybe the programmer in question actually wants to make a distinction between the two, and there's nothing wrong with doing that either.

> because if you pass a struct as param, the param is never null !

So what? An array isn't a struct.

>
> I'm against the shortcut...it doesn't help to understand how it works. It's a useless and confusing shortcut. Warning about the amibuous usage was the right
> to do.

I don't think it's confusing. Also note that the shortcut (=> length) is much more likely to be correct. There are lots of non-null empty arrays, but I don't know a non-contrived way to accidentally end up with a non-empty null array.

On Friday, 10 April 2015 at 15:57:09 UTC, Andrei Alexandrescu wrote:
> On 4/10/15 6:26 AM, Meta wrote:
>> On Friday, 10 April 2015 at 12:42:47 UTC, Steven Schveighoffer wrote:
>>> Plus, adding arr.empty into object is kind of redundant. The only
>>> reason we have arr.empty is so that it becomes a range.
>>>
>>> -Steve
>>
>> I find it extremely annoying to have to import std.array (or whatever
>> the correct module is) just to use .empty, .front and .popFront on
>> arrays. IMO they should all be in object.d.
>
> Yah, I was about to post the same. Range semantics are embedded in the language enough to warrant this.
>
> Also empty should work for AAs.
>
>
> Andrei

I was going to suggest this myself, but I thought it would be too much. Having to import std.array to make std.algorithm work with slices is a bit of a curve ball for very new D programmers. They tend to do this...

import std.algorithm;

void main() {
    int[] arr = [1, 2, 3];

    arr = arr.map!(x => x * 2);
}

Then they get a compile time error and ask why it didn't work. It doesn't matter too much, but it is something you have to learn on your first day or so.

On 4/10/15 10:28 AM, Steven Schveighoffer wrote:
> On 4/10/15 11:57 AM, Andrei Alexandrescu wrote:
>> On 4/10/15 6:26 AM, Meta wrote:
>>> On Friday, 10 April 2015 at 12:42:47 UTC, Steven Schveighoffer wrote:
>>>> Plus, adding arr.empty into object is kind of redundant. The only
>>>> reason we have arr.empty is so that it becomes a range.
>>>>
>>>> -Steve
>>>
>>> I find it extremely annoying to have to import std.array (or whatever
>>> the correct module is) just to use .empty, .front and .popFront on
>>> arrays. IMO they should all be in object.d.
>>
>> Yah, I was about to post the same. Range semantics are embedded in the
>> language enough to warrant this.
>>
>> Also empty should work for AAs.
>
> How should "abc".front work? Do you want to move unicode decoding of
> char and wchar arrays into object.d? Serious question, not rhetorical,
> because I'm not for or against it (except for the notion of changing
> things for the sake of changing them), I just want to point out what is
> required.

Should decode. Meaning there's no change of semantics, just where the facility is defined. -- Andrei

On 4/10/15 1:39 PM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
> On Friday, 10 April 2015 at 10:09:18 UTC, jkpl wrote:
>> Then, imagine that the syntactic shortcut is accepted, this would lead
>> to the following confusion:
>> ---
>> char[] * arr;
>> if(arr)
>> ---
>> Here the test is really about the array being null or not.
>
> `arr` is a pointer, not an array. I don't understand what you're arguing
> here.
>
>>
>> It's like in the topic from yesterday:
>>
>> ---
>> void a(uint p, string a = null){}
>> ---
>>
>> Totally wrong, the guy should write:
>>
>> ---
>> void a(uint p, string a = ""){}
>> ---
>>
>
> I don't know what that topic was about, but there is nothing obviously
> wrong with either version. The language mostly treats both the same way:
>
>      string nullstr = null;
>      assert(nullstr == "");
>      assert(nullstr.length == 0);
>
> The only difference is that "" has a non-null address:
>
>      assert(!nullstr.ptr);
>      assert("".ptr);
>
> OTOH, maybe the programmer in question actually wants to make a
> distinction between the two, and there's nothing wrong with doing that
> either.
>
>> because if you pass a struct as param, the param is never null !
>
> So what? An array isn't a struct.
>
>>
>> I'm against the shortcut...it doesn't help to understand how it works.
>> It's a useless and confusing shortcut. Warning about the amibuous
>> usage was the right
>> to do.
>
> I don't think it's confusing. Also note that the shortcut (=> length) is
> much more likely to be correct. There are lots of non-null empty arrays,
> but I don't know a non-contrived way to accidentally end up with a
> non-empty null array.

I know of one place that has a non-empty null array, TypeInfo.init():

import std.stdio;

struct S
{
    int x;
}

void main()
{
    auto x = typeid(S).init();
    writeln(x.ptr, " ", x.length);
}

output:
null 4

The reason for this is, the compiler is telling you the size is 4 bytes, but they should all be 0 (no need to store 0 bytes in data segment).

But this is NOT a usual situation.

-Steve