Is D still alive?

[Jonathan M Davis]

On Wednesday 26 January 2011 17:52:19 spir wrote:
> On 01/27/2011 02:11 AM, Jonathan M Davis wrote:
> > On Wednesday, January 26, 2011 16:41:10 spir wrote:
> >> On 01/26/2011 11:33 PM, Trass3r wrote:
> >>>> For me, D's killer features were string handling (slicing and
> >>>> appending/concatenation) and *no header files*. (No more header
> >>>> files!! Yay!!!). But auto is fantastic too though, I get sooo much
> >>>> use out of that.
> >>> 
> >>> Getting rid of the pointer crap (proper arrays, bounds checking,
> >>> classes as reference types,...) is definitely among the top 10 on my
> >>> list.
> >> 
> >> Same here. But I would prefere slicing not to check upper bound, rather
> >> just extend to the end. Or have a slicing variant do that.
> > 
> > You mean that if you give an index which is too large, it just uses $
> > instead? That sounds seriously bug-prone to me. I'd much rather that it
> > blew up and thus told me that my program had a bug in it rather than
> > silently trying to work.
> 
> Sorry, but you are wrong on this. I understand this sounds unsafe, but no.
> Most languages, I guess, just do that without any worry. In particular, I
> have frequented python and Lua mailing lists for years without even
> reading once about this beeing a misfeature (and indeed have never run
> into a bug because of this myself). It is simply the right semantics in
> 99.999% cases.
> 
> spir at d:~$ python
> Python 2.6.6 (r266:84292, Sep 15 2010, 15:52:39)
> [GCC 4.4.5] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> 
> >>> s = 'abc'
> >>> s[0:123456789]
> 
> 'abc'
> 
> spir at d:~$ lua
> Lua 5.1.4  Copyright (C) 1994-2008 Lua.org, PUC-Rio
> 
> > require"io"
> > s = "abc"
> > print(string.sub(s, 1, 123456789))
> 
> abc
> 
> I'm constantly annoyed by D's behaviour. For instance, often have to write
> out the end of a string from a given point, but only at most n chars (to
> avoid cluttering the output, indeed):
> 	writeln(s[i..i+n]);
> which fails if there are less than n remaining chars ;-)

I _rarely_ see cases where I would consider it okay to give an index for the end 
of an array and having that index be too large is a good thing. It invariably 
means that your algorithm is wrong. In my experience, if you really need to know 
what the size of your array is and handle it properly.  There _are_ cases where 
you say that you want "the rest" of the array or collection and don't care how 
much that is, but in cases where you're actually looking to specify the index, 
if the index is wrong, then the code is wrong.

Now, I suppose that there are cases where you could simplify an algorithm where 
you effectively be n or less (if there aren't n elements left). But that's 
definitely atypical in my experience, and writing a wrapper function for such a 
case is trivial. Generally speaking, I'd be very worried about code which was 
lax enough about indices to not care whether it was indexing passed the end of 
the array or not.

Clearly, if you think that not being strict about indices is a good idea, you're 
either dealing with very different circumstances than I have and/or you're coding 
very differently. Regardless, since it's trivial to create a wrapper that does 
what you want, I don't think that there's any reason to change how slicing 
works.

- Jonathan M Davis