On 4/10/15 7:18 AM, bearophile wrote:
> Martin Krejcirik:
>
>> I agree, people should just use arr.length.
>
> People should probably use "arr.empty".
>

empty is a negative. I'd prefer if(arr.length) instead of if(!arr.empty), as the latter's a double-negative.

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

On 4/10/15 7:39 AM, Vladimir Panteleev wrote:
> On Thursday, 9 April 2015 at 20:59:00 UTC, Steven Schveighoffer wrote:
>> What do you think?
>
> Well, that's a pretty one-sided description of the argument!

So, what's the other side? :) I'm only on one side of the argument, I don't want to misrepresent your side.

> The tools repository is occasionally used as a guinea pig for breaking
> changes. Consider the amount of changes needed here, as an example:
>
> https://github.com/D-Programming-Language/tools/pull/166/files

I did include this link in my OP. I wasn't trying to hide anything.

Frankly, that list of changes is quite small (40 lines). We already have another poster who had to change 1000 lines, and most of them were incorrect before the change.

-Steve

On 4/10/15 5:35 AM, John Colvin wrote:
>
> As others have mentioned, why not make if(arr) be equivalent to
> if(arr.length)? It seems that's what everyone actually wants when they
> type it.

Some code legitimately uses if(arr) to check the pointer (see link to the tools change that I posted originally). This code would compile, but silently change semantic. Such breaking changes are the worst kind, and should not be allowed.

In all honesty, I don't really care if we ever reintroduce if(arr) again, typing if(arr.length) is not that bad, and clarifies the intent.

-Steve

On Thu, 09 Apr 2015 16:59:00 -0400, Steven Schveighoffer wrote:

> A confusing and dangerous "feature" of D was to treat the expression
> if(arr) as meaning if(arr.ptr).
> 
> Anyone coming from any number of other languages may think that if(arr) means "if arr has any elements". Typically one cares what is inside an array, not where it lives.
> 
> However, while checking to see if an array has elements is very similar
> to checking for a null pointer (obviously, a null pointer array should
> have no elements), it's not equivalent. Therefore, when attempting to
> fix this confusion, we had to disable the if(arr) check altogether. You
> must now specify what part of the array you care about, if(arr.ptr) or
> if(arr.length).
> 
> As usual with changes of this nature, there are differing opinions, and differing styles. I personally never use null as a special value for an array, but others do. They use if(arr) to actually mean if(arr.ptr). For these cases, the update will cause some amount of busywork changing these checks.
> 
> But when updating Phobos to comply with this change, we found several actual incorrect usages. So I think the change is worth it, and not much busywork. YMMV.
> 
> What do you think?

this is good, as `if (arr.ptr)` is really confusing. yet i can't understand why don't rewrite it to `if (arr.length)` instead.

On Fri, 10 Apr 2015 20:30:16 +1000, Daniel Murphy wrote:

> "Martin Nowak"  wrote in message news:lgjobvhvilvdymfatoje@forum.dlang.org...
> 
>> I've been thinking about moving std.array.empty to object. Then that could more easily become the replacement idiom.
>>
>> if (arr) -> if (!arr.empty)
>>
>> It's much clearer and also what you need to write when you work with ranges.
> 
> if (arr.length) is just as clear, and the same thing.
> 
> 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.

On Fri, 10 Apr 2015 12:53:43 +0000, ketmar wrote:

> this is good, as `if (arr.ptr)` is really confusing. yet i can't
> understand why don't rewrite it to `if (arr.length)` instead.

$#^%@$. i should really read the whole topic before writing answers.

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.

On 4/10/15 9: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.
>
> 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.

If only it were that easy... The problem is char[] (or rather, the insistence of Phobos that char[] is not an array).

-Steve

"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.

It's like this code:

uint x;

if (x > 0) {}

if (x != 0) {}

Both of those if conditions are the same, but you'll use one or the other depending on context. 

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."