[Submission] D Slices

[Nick Sabalausky]

"eles" <eles at eles.com> wrote in message news:is3j1h$thh$1 at digitalmars.com...
>> a few reasons (in no particular order):
>> 1. After years of using D, I've never had a problem with it working
> that
>> way. And even initially, I found it very easy to learn and get used
> to it.
>
> You become an "educated" user. How many? I bet that *you* will never
> write
>
> while(some_condition);
> do_some_intended_loop_processing();
>
> but this happens!
>
> What to do when it happens?
>

That's a syntax error in D.


>> 2. I've found it easier to avoid off-by-one errors. I don't have to
> think
>> about them as much.
>
> Why? I fail to see the reason behind.

Seriously, I've just stated that that's been my experience. Whether or not I 
can give a reason for why that's been my experience is irrelevent. If I 
couldn't give a reason, would that somehow change the fact of what I 
experienced? Of course not.

> It would be simply as
> substracting 1 from the right limit. Is this more prone to errors?
>

In my experience, yes.


>> 3. arr[a..b].length == b-a     <-- That's a *very* nice, clean,
> useful
>> property to have. And I think it's one of the main reasons for #2
> above. In
>> fact, this actually makes it feel more balanced to me than having
> inclusive
>> on both ends.
>
> Speaking of this, using an alternative syntax such as a
> [slice_beginning..slice_length] would even allow you to not even make
> that substraction in the first place, let alone adding 1.
>

Using [slice_beginning..slice_length] is essentially like mixing types. You 
have an index and then you have a length. If you want to use the end of that 
slice as the beginning of another slice, you have to convert it from length 
to index. If you want to use the start of the slice as the end of another 
slice, you have to convert it from index to length.

But the way we do it now, you just have two indicies. The same "type", so to 
speak. So why not use what's simpler? ;)

> But the fact is that when you are counting numbers going from 6 to 9,
> to find *the number of numbers* you do: 9-6 PLUS 1.
>

That's not even relevent.

>> 4. The following:
>> string str = "ABCDEF";
>> int splitIndex = 3;
>> string part1 = str[0 .. splitIndex];
>> string part2 = str[splitIndex .. $];
>> assert(part1 ~ part2 == str);
>> Ie, when you split an array, you can use the same index for both
> halves. No
>> "+1"-ing. It just works. Don't have to think about it.
>
> You can live a life without having to think about many things.
> However, experience proves that thinking is generally better than not
> "having to think about it". What if a bug?
>

That's one of the most rediculous arguments I've heard. If I started typing 
everything in "leet" or pig latin, you'd have to think a lot more to read 
it, and I'd have to think a lot more to write it, but it sure as hell 
wouldn't improve anything because it's thinking about things that we don't 
actually need to think about.

> Is not more logically to index those halves with:
>
> a[0..length_half-1]
> a[length_half..length-1]
>

Yes, that is not more logical. It's less logical and more messy.

> We speak about *disjoint* halves here. Why not disjoint indexes?
>
> What if you have a "center" (common) character that you want to keep
> in both halves?
>
> You would have to write:
>
> string part1 = str[0 .. splitIndex+1];
> string part2 = str[splitIndex .. $];
>
> Is this more logical than writing:
>
> string part1 = str[0 .. splitIndex];
> string part2 = str[splitIndex .. $];
>
> ?
>

First of all, yes, the first *is* more logical simply because you're 
deliberately duplicating an element, therefore it makes sense there would be 
an adjustment to one of the endpoints.

Secondly, when would anyone ever need to do that? It's obviously only a rare 
need at best. I'm getting the impression that you're just making up 
arguments for the sake of arguing.