Is D still alive?

[Jonathan M Davis]

On Wednesday 26 January 2011 19:06:37 Jonathan M Davis wrote:
> 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.

I should probably add that it's more efficient to have the built-in slicing 
facilities be exact and build inexact ones on top of that then it is to make 
them inexact and the build exact ones on top. When you get down to it, you 
_have_ to slice _exactly_ when you get down deep enough in the code. So, making 
the slicing then be exact on top of that doesn't really cost anything. But 
adding the extra checks to make the inexact one work adds extra cost. So, while 
that's fine if the inexact behavior is what you want, it's _not_ fine if it's the 
exact behavior that you want, since then unnecessary checks are happening in the 
middle. For efficiency reasons, the exact behavior _needs_ to be the default.

exact -> low level exact and inexact -> exact -> low level exact works as 
efficiently as is possible. Whereas having inexact -> low level exact and exact -> 
inexact -> low level exact is _not_ efficient.

- Jonathan M Davis