Lets deprecate the length in the arrays index

[janderson]

Chris Nicholson-Sauls wrote:
> janderson wrote:
>> Lionello Lunesu wrote:
>>> Frank Benoit (keinfarbton) wrote:
>>>> There was this thread:
>>>>
>>>
> 
> Even though this is just a contrived example, I still have to say that 
> line ought to just expose a method for this operation, perhaps a 
> findSlice(a,b).  If and when we get Tuples as return values one could 
> also use that if you wanted to keep the find and slice operations 
> seperated.
> 
> I'm just very wary of the []==with concept.  Its unintuitive, still 
> causes the same namespace issues as [length], and even creates new 
> ones.  Honestly, I've often wondered if something other than the dot 
> operator should be found for built-in properties (and even for non 
> built-in ones, but that goes back to my desire for an explicit property 
> syntax, alas).  Sadly, I have no idea what else to use, except maybe a 
> colon (:) but that poor baby is getting burdened already, and could 
> still be ambiguous (consider `case int.max: ...;` versus `case int:max: 
> ...;` -- ack).
> 
> -- Chris Nicholson-Sauls

I try to avoid methods for these type of operations when clearly you 
have access to all you need outside the class.  Free functions are so 
much more manageable and reuseable.  This is particularly the case if 
the array was in some stand lib.

I'm not to worried about the namespacing issue, you still could use the 
. operator if you need to.   Of course there's the issue of 
case-sensitive and type-o errors, but must coders are used to dealing 
with them.

I do agree that a findSlice would be a good idea, however if you look at 
the internals, you end up writing the longer bit of code again.  Of 
course I would recommend it being written safely like:

int first = line.find('a');
int last = line.find('b');

if (first < last)
{
    return line[first...last];
}

ect... (or throw an exception or whatever).

-Joel