View mode: basic / threaded / horizontal-split · Log in · Help
March 21, 2012
What about putting array.empty in object.d?
Hear me out... ;)

Using empty seems to be emerging as the recommended practice for testing 
whether an array is empty. And that makes sense as it's consistent with 
other ranges. I'm all in favor of that.

But I've found myself avoiding empty (and instead doing arr=="" or checking 
the .length) just because empty doesn't work on arrays unless you've already 
imported std.array (unless my knowledge is out-of-date, which is possible 
considering how fast things are moving ;) ). So doing "arr.empty" is a 
little messy and increases my cognitive load, whereas arr=="", arr==[], and 
arr.length == 0, "just work".

Considering that:

1. Arrays are (from the user's perspective) a built-in type that doesn't 
need to be explicitly imported.

2. Calling 'empty' is (for good reason) the recommended standard practice 
for checking if arrays are empty.

...Perhaps it would make sense for empty(T)(T[] a) to be moved into 
object.d, or at least somewhere it will always be implicitly included? Being 
a standard part of arrays and input ranges already effectively elevates 
"empty" to a relatively special status anyway.
March 21, 2012
Re: What about putting array.empty in object.d?
On 3/21/12, Nick Sabalausky <a@a.a> wrote:
> Hear me out... ;)

Man I would say the same thing about write() functions. I've missed
importing std.stdio so many times. It doesn't help that the compiler
happily asks me if I've missed an import to std.stdio. But I digress..

I use .length all the time. I also use them on hashes and it sucks
that .empty isn't defined for them (it's not in std.array).
March 21, 2012
Re: What about putting array.empty in object.d?
On Wed, Mar 21, 2012 at 05:27:01AM +0100, Andrej Mitrovic wrote:
> On 3/21/12, Nick Sabalausky <a@a.a> wrote:
> > Hear me out... ;)
> 
> Man I would say the same thing about write() functions. I've missed
> importing std.stdio so many times. It doesn't help that the compiler
> happily asks me if I've missed an import to std.stdio. But I digress..
> 
> I use .length all the time. I also use them on hashes and it sucks
> that .empty isn't defined for them (it's not in std.array).

Good point! I'll have to add .empty to my AA implementation. ;-)


T

-- 
A computer doesn't mind if its programs are put to purposes that don't
match their names. -- D. Knuth
March 21, 2012
Re: What about putting array.empty in object.d?
FWIW, I would rather see `if (array)` translated to `if (array.length)` and 
this become the recomended way to check if an array is empty.  Wouldn't that 
remove the dependency on std.array for most of the cases?
March 21, 2012
Re: What about putting array.empty in object.d?
On 2012-03-21 04:54, Nick Sabalausky wrote:
> Hear me out... ;)
>
> Using empty seems to be emerging as the recommended practice for testing
> whether an array is empty. And that makes sense as it's consistent with
> other ranges. I'm all in favor of that.
>
> But I've found myself avoiding empty (and instead doing arr=="" or checking
> the .length) just because empty doesn't work on arrays unless you've already
> imported std.array (unless my knowledge is out-of-date, which is possible
> considering how fast things are moving ;) ). So doing "arr.empty" is a
> little messy and increases my cognitive load, whereas arr=="", arr==[], and
> arr.length == 0, "just work".
>
> Considering that:
>
> 1. Arrays are (from the user's perspective) a built-in type that doesn't
> need to be explicitly imported.
>
> 2. Calling 'empty' is (for good reason) the recommended standard practice
> for checking if arrays are empty.
>
> ...Perhaps it would make sense for empty(T)(T[] a) to be moved into
> object.d, or at least somewhere it will always be implicitly included? Being
> a standard part of arrays and input ranges already effectively elevates
> "empty" to a relatively special status anyway.

Sure, why not. Do we want an "any" function as well, that is the opposite?

-- 
/Jacob Carlborg
March 21, 2012
Re: What about putting array.empty in object.d?
"Jacob Carlborg" <doob@me.com> wrote in message 
news:jkc321$25pv$1@digitalmars.com...
> On 2012-03-21 04:54, Nick Sabalausky wrote:
>> Hear me out... ;)
>>
>> Using empty seems to be emerging as the recommended practice for testing
>> whether an array is empty. And that makes sense as it's consistent with
>> other ranges. I'm all in favor of that.
>>
>> But I've found myself avoiding empty (and instead doing arr=="" or 
>> checking
>> the .length) just because empty doesn't work on arrays unless you've 
>> already
>> imported std.array (unless my knowledge is out-of-date, which is possible
>> considering how fast things are moving ;) ). So doing "arr.empty" is a
>> little messy and increases my cognitive load, whereas arr=="", arr==[], 
>> and
>> arr.length == 0, "just work".
>>
>> Considering that:
>>
>> 1. Arrays are (from the user's perspective) a built-in type that doesn't
>> need to be explicitly imported.
>>
>> 2. Calling 'empty' is (for good reason) the recommended standard practice
>> for checking if arrays are empty.
>>
>> ...Perhaps it would make sense for empty(T)(T[] a) to be moved into
>> object.d, or at least somewhere it will always be implicitly included? 
>> Being
>> a standard part of arrays and input ranges already effectively elevates
>> "empty" to a relatively special status anyway.
>
> Sure, why not. Do we want an "any" function as well, that is the opposite?
>

I think "!array.empty" is plenty sufficient. Besides, there are other good 
uses of "any" that have been brought up before.
March 21, 2012
Re: What about putting array.empty in object.d?
On 2012-03-21 09:42, Nick Sabalausky wrote:
> "Jacob Carlborg"<doob@me.com>  wrote in message
>> Sure, why not. Do we want an "any" function as well, that is the opposite?
>>
>
> I think "!array.empty" is plenty sufficient. Besides, there are other good
> uses of "any" that have been brought up before.

Actually I was thinking something like "any?" in Ruby:

http://www.ruby-doc.org/core-1.8.7/Enumerable.html#method-i-any-3F

-- 
/Jacob Carlborg
March 21, 2012
Re: What about putting array.empty in object.d?
On Wed, 21 Mar 2012 00:54:51 -0400, Daniel Murphy  
<yebblies@nospamgmail.com> wrote:

> FWIW, I would rather see `if (array)` translated to `if (array.length)`  
> and
> this become the recomended way to check if an array is empty.  Wouldn't  
> that
> remove the dependency on std.array for most of the cases?

+1

-Steve
March 21, 2012
Re: What about putting array.empty in object.d?
On Wednesday, 21 March 2012 at 04:54:54 UTC, Daniel Murphy wrote:
> FWIW, I would rather see `if (array)` translated to `if 
> (array.length)` and
> this become the recomended way to check if an array is empty.  
> Wouldn't that
> remove the dependency on std.array for most of the cases?

Nope. .length is a requirement for finite random-access ranges, 
but not for forward or bidirectional ranges. .empty is the only 
primitive required by all input ranges.

So if you pass an array to a function expecting a forward range, 
it may not work if the primitive .empty doesn't exist.
March 21, 2012
Re: What about putting array.empty in object.d?
On Wed, 21 Mar 2012 11:50:46 -0400, Xinok <xinok@live.com> wrote:

> On Wednesday, 21 March 2012 at 04:54:54 UTC, Daniel Murphy wrote:
>> FWIW, I would rather see `if (array)` translated to `if (array.length)`  
>> and
>> this become the recomended way to check if an array is empty.  Wouldn't  
>> that
>> remove the dependency on std.array for most of the cases?
>
> Nope. .length is a requirement for finite random-access ranges, but not  
> for forward or bidirectional ranges. .empty is the only primitive  
> required by all input ranges.
>
> So if you pass an array to a function expecting a forward range, it may  
> not work if the primitive .empty doesn't exist.

from std/range.d:

module std.range;

public import std.array;

-Steve
« First   ‹ Prev
1 2 3
Top | Discussion index | About this forum | D home