"eles" <e...@eles.com> wrote in message news:is3j1h$thh$1...@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.
