www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - in operator for dynamic arrays

reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
In case it hasn't been requested before, it would be nice if the 'in' 
operator found the first occurrence in a dynamic array if present. So
  char[] str;
  ...
  int n = ':' in str;
returned the index of the first ':' or -1 if not present (generalizing 
std.string.find to any array). One could even imagine making 'in' work for 
sub-arrays:
  int n = "::" in str;
Note that 'key in AA' returns a pointer to the value or null so potentially 
one could use the same return values for dynamic arrays but it seems like 
the index is more useful even though it means conditionals will look like
  if (0 in x == -1)
instead of
  if (0 in x)
Jun 04 2005
parent reply Michael Butscher <mbutscher gmx.de> writes:
Ben Hinkle wrote:
 In case it hasn't been requested before, it would be nice if the 'in' 
 operator found the first occurrence in a dynamic array if present. So
   char[] str;
   ...
   int n = ':' in str;
 returned the index of the first ':' or -1 if not present (generalizing 
 std.string.find to any array). One could even imagine making 'in' work for 
 sub-arrays:
   int n = "::" in str;
 Note that 'key in AA' returns a pointer to the value or null so potentially 
 one could use the same return values for dynamic arrays but it seems like 
 the index is more useful even though it means conditionals will look like
   if (0 in x == -1)
 instead of
   if (0 in x)

This would mean that in behaves differently for associative and dynamic (why not also static?) arrays. I would prefer that a pointer is returned: char* p = ':' in str; The index can then be retrieved by (p - str.ptr) after checking for a null pointer. This expression also works if the base type has a size greater than 1 (e. g. for int pointer/array). Michael
Jun 07 2005
parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Michael Butscher" <mbutscher gmx.de> wrote in message 
news:MPG.1d100a65d86fcd69989689 news.digitalmars.com...
 Ben Hinkle wrote:
 In case it hasn't been requested before, it would be nice if the 'in'
 operator found the first occurrence in a dynamic array if present. So
   char[] str;
   ...
   int n = ':' in str;
 returned the index of the first ':' or -1 if not present (generalizing
 std.string.find to any array). One could even imagine making 'in' work 
 for
 sub-arrays:
   int n = "::" in str;
 Note that 'key in AA' returns a pointer to the value or null so 
 potentially
 one could use the same return values for dynamic arrays but it seems like
 the index is more useful even though it means conditionals will look like
   if (0 in x == -1)
 instead of
   if (0 in x)

This would mean that in behaves differently for associative and dynamic (why not also static?) arrays. I would prefer that a pointer is returned: char* p = ':' in str; The index can then be retrieved by (p - str.ptr) after checking for a null pointer. This expression also works if the base type has a size greater than 1 (e. g. for int pointer/array). Michael

Why would you prefer a pointer? Is it to match AA's? I'm curious why. In terms of practical use I still believe an index is more useful. The argument that a pointer would facilitate generic code isn't practical since using 'in' to find the first value in a dynamic array is significantly different enough from AA key lookups. I can't imagine much generic code that would use 'in' for both AAs and dynamic arrays.
Jun 07 2005
next sibling parent reply "Kris" <fu bar.com> writes:
While perhaps nice on the surface, I'm thinking this idea has some hidden
gotcha's in it when it comes to UTF encoding. Would this be expected to
perform hidden utf conversion in any shape or form?

To address Ben's question about indexing: would the function return the
character index, or the array index? They are often not the same in UTF.


"Ben Hinkle" <ben.hinkle gmail.com> wrote in message
news:d859fb$adl$1 digitaldaemon.com...
 "Michael Butscher" <mbutscher gmx.de> wrote in message
 news:MPG.1d100a65d86fcd69989689 news.digitalmars.com...
 Ben Hinkle wrote:
 In case it hasn't been requested before, it would be nice if the 'in'
 operator found the first occurrence in a dynamic array if present. So
   char[] str;
   ...
   int n = ':' in str;
 returned the index of the first ':' or -1 if not present (generalizing
 std.string.find to any array). One could even imagine making 'in' work
 for
 sub-arrays:
   int n = "::" in str;
 Note that 'key in AA' returns a pointer to the value or null so
 potentially
 one could use the same return values for dynamic arrays but it seems



 the index is more useful even though it means conditionals will look



   if (0 in x == -1)
 instead of
   if (0 in x)

This would mean that in behaves differently for associative and dynamic (why not also static?) arrays. I would prefer that a pointer is returned: char* p = ':' in str; The index can then be retrieved by (p - str.ptr) after checking for a


 pointer. This expression also works if the base type has a size greater
 than 1
 (e. g. for int pointer/array).


 Michael

Why would you prefer a pointer? Is it to match AA's? I'm curious why. In terms of practical use I still believe an index is more useful. The argument that a pointer would facilitate generic code isn't practical

 using 'in' to find the first value in a dynamic array is significantly
 different enough from AA key lookups. I can't imagine much generic code

 would use 'in' for both AAs and dynamic arrays.

Jun 07 2005
parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Kris" <fu bar.com> wrote in message news:d85d7n$d4r$1 digitaldaemon.com...
 While perhaps nice on the surface, I'm thinking this idea has some hidden
 gotcha's in it when it comes to UTF encoding. Would this be expected to
 perform hidden utf conversion in any shape or form?

 To address Ben's question about indexing: would the function return the
 character index, or the array index? They are often not the same in UTF.

I would it expect it to behave like std.string.find (and the rest of the char[] functions) and work with array indices. Using 'in' with dchars or UTF8 fragments would be nice, too.
 "Ben Hinkle" <ben.hinkle gmail.com> wrote in message
 news:d859fb$adl$1 digitaldaemon.com...
 "Michael Butscher" <mbutscher gmx.de> wrote in message
 news:MPG.1d100a65d86fcd69989689 news.digitalmars.com...
 Ben Hinkle wrote:
 In case it hasn't been requested before, it would be nice if the 'in'
 operator found the first occurrence in a dynamic array if present. So
   char[] str;
   ...
   int n = ':' in str;
 returned the index of the first ':' or -1 if not present (generalizing
 std.string.find to any array). One could even imagine making 'in' work
 for
 sub-arrays:
   int n = "::" in str;
 Note that 'key in AA' returns a pointer to the value or null so
 potentially
 one could use the same return values for dynamic arrays but it seems



 the index is more useful even though it means conditionals will look



   if (0 in x == -1)
 instead of
   if (0 in x)

This would mean that in behaves differently for associative and dynamic (why not also static?) arrays. I would prefer that a pointer is returned: char* p = ':' in str; The index can then be retrieved by (p - str.ptr) after checking for a


 pointer. This expression also works if the base type has a size greater
 than 1
 (e. g. for int pointer/array).


 Michael

Why would you prefer a pointer? Is it to match AA's? I'm curious why. In terms of practical use I still believe an index is more useful. The argument that a pointer would facilitate generic code isn't practical

 using 'in' to find the first value in a dynamic array is significantly
 different enough from AA key lookups. I can't imagine much generic code

 would use 'in' for both AAs and dynamic arrays.


Jun 07 2005
prev sibling parent Michael Butscher <mbutscher gmx.de> writes:
Ben Hinkle wrote:
 
 "Michael Butscher" <mbutscher gmx.de> wrote in message 
 news:MPG.1d100a65d86fcd69989689 news.digitalmars.com...
 Ben Hinkle wrote:
 In case it hasn't been requested before, it would be nice if the 'in'
 operator found the first occurrence in a dynamic array if present. So
   char[] str;
   ...
   int n = ':' in str;
 returned the index of the first ':' or -1 if not present (generalizing
 std.string.find to any array). One could even imagine making 'in' work 
 for
 sub-arrays:
   int n = "::" in str;
 Note that 'key in AA' returns a pointer to the value or null so 
 potentially
 one could use the same return values for dynamic arrays but it seems like
 the index is more useful even though it means conditionals will look like
   if (0 in x == -1)
 instead of
   if (0 in x)

This would mean that in behaves differently for associative and dynamic (why not also static?) arrays. I would prefer that a pointer is returned: char* p = ':' in str; The index can then be retrieved by (p - str.ptr) after checking for a null pointer. This expression also works if the base type has a size greater than 1 (e. g. for int pointer/array). Michael

Why would you prefer a pointer? Is it to match AA's? I'm curious why.

I think that a pointer would be more practical (see below) and I personally prefer that the same keyword behaves the same way as far as possible.
 In terms of practical use I still believe an index is more useful. The 
 argument that a pointer would facilitate generic code isn't practical since 
 using 'in' to find the first value in a dynamic array is significantly 
 different enough from AA key lookups. I can't imagine much generic code that 
 would use 'in' for both AAs and dynamic arrays. 

I agree with you here. For AA's the "in" searches the keys while for dynamic arrays it searches the values (the keys would be the indexes, searching them wouldn't be senseful). But I can't see why indexes should be more practical. I think, there are two main uses for "in" on dynamic arrays: - To test if a value is in the array or not. Testing a pointer would be shorter for that. - To modify the found value in the array. Your proposal would mean that the retrieved index must be first converted to a pointer (in the machine code) to access the value.
Jun 08 2005