Is D still alive?

[Jonathan M Davis]

On Thursday, January 27, 2011 01:34:04 bearophile wrote:
> spir:
> > 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.
> 
> Thank you for raising this topic again. I have raised it probably more than
> one year ago, and all people around here were against this. This is not
> unsafe, it's actually safer than the current D behaviour. Python designers
> don't think this is a badly designed part of Python, they think this is as
> desired, and I too have never seen people complain about this being a bad
> or bug prone design.
> 
> An example of Python code:
> 
> s = "abcdefg"
> upper = 20
> s2 = s[2 : upper]
> assert s2 == "cdefg"
> 
> Equivalent D2 code, if you forget to use the min() you are doomed:
> 
> import std.algorithm: min;
> void main() {
>     string s = "abcdefg";
>     int upper = 20;
>     string s2 = s[2 .. min($, upper)];
>     assert(s2 == "cdefg");
> }
> 
> The saturating nature of Python slice bounds is a safety net that's useful
> to avoid some troubles. The only good thing of the D2 design is that it
> performs less tests at runtime (it has no need to call min() in general),
> this is a bit positive in a system language, but in this case it has a
> cost in safety.

I don't think that you stand much chance of convincing a crowd using a system 
programming language that having the compiler adjust your out of bound indices 
to be in bounds is  good idea. While it may be a great idea in some 
circumstances, it generally smacks of lax programming. And since it makes 
slicing more expensive, it would be a feature that would definitely need to pull 
its weight. And I don't see how it possibly could. It's trivial to add a 
function which will return a slice which is laxly sliced in the manner that 
you're looking for. And using min as you're showing isn't exactly hard.

Yes, you may get bugs when porting code from Python, but I don't think that 
porting Python code has ever been one of the major concerns of D's language 
design. Really, it's the silently breaking stuff when porting C and C++ code 
which has been the concern.

What we have is efficient, and I expect that most people around here think that 
it's the correct solution. If you want lax slicing, it's easy to get by using 
min or a wrapper function. So, I see no reason to make any language changes - 
not to mention it would likely conflict with TDPL to make such a change.

- Jonathan M Davis