[Submission] D Slices

Timon Gehr timon.gehr at gmx.ch
Sat Jun 11 10:07:53 PDT 2011


eles wrote:
>> This is not practical.  It would be too expensive to check because
>> the
>> hardware does not support it.
>
> neither does for bounds checking. expensiveness does not matter so
> much in the debug version.
>
>> As has been said, multiple times, UTYPE_MAX is not a valid index,
> and that
>> is not because of the open-interval on the right.  It's because of
>> addressing in a zero-based index world, you simply can't have an
>> array
>> bigger than your address space.  An array with UTYPE_MAX as a valid
>> index
>> must have at least UTYPE_MAX + 1 elements.
>
> well, on unsigned nbits=3, UTYPE_MAX =7 and that's a valid index, as
> you write a[0]..a[7]. the array has UTYPE_MAX+1 elements (ie.
> "length", aka "$") and this is exactly why mentioning "$" as "length"
> instead of "last element" is inconsistent when you write a[0..$] (the
> second index is, *with this syntax* UTPE_MAX+1 and is not
> representable)

Yes, but that just means that you cannot represent the length of your array with
your machine word size. Such an array is meaningless. It does not fit in your
memory. You do not have a case here.

However, your argument could be extended to foreach-range statements:

// loop over all possible ubyte values:
foreach(i;ubyte.min..ubyte.max+1){...} // does not work, because ubyte.max+1 overflows

// possible fix:
foreach(_i;0..256){ubyte i=_i;...}

I agree that half-open intervals are not the best choice for this _special case_.
They are very nice for all the other cases though.
Oh, and yes they simplify the implementation of foreach and make it more efficient
because the compiler does not have to care about overflow.
With half-open intervals, your iteration variable _cannot_ overflow, so no need to
check for that.

Now, what is more important: The 256 cases where your interval iterated over ends
at 255 or the ~32'000 cases were it does not?
The same argument gets much stronger if the type iterated over is bigger in size.

The closed-right solution has a special case too:

How do you represent the empty interval ending at UTYPE_MAX?
How do you represent the empty interval beginning at 0?

:o).

>
>> But, it's not really important anyways.  The open-right indexing
>> ship has
>> not only sailed, it's made it across the ocean, formed several
>> colonies,
>> and is currently declaring independence.
>
> Even if independence is acquired, empires are doomed to fall in the
> end. See China rising.

The same argument applies to the empire of closed-right intervals.

>
>
>> You're about a decade too late
>> with this argument.
>
> well, C++ standards gave the same answers when changes were proposed,
> this is why the need for D in the first place. age of a choice does
> not make it any better. there are good and bad habits. see the famous
> "< <" *recommendation* for writing in templates in order to not
> conflict with "<<" operator.
>
>> How much of a possibility would you think Matlab has of changing its
>> indexing scheme to be like D's?  About the same chance as D adopting
>> Matlab's, I'd say.
>
> what about multi-dimensional slicing?

Thats very special-purpose and does not play with Ds reference semantics for
slices that well or even at all.
A library solution might implement different semantics for such a thing, maybe
closer to matlab. Ds operator overloading capabilities are of help here.
Matlab is a scripting language optimized for use in linear-algebra computations. D
is a general-purpose language.
I think it is natural that D does not support the same things out of the box.

>
>>  If this is a reason you will not use D, then I'm sorry
>> that you won't be with us, but that's just life.
>
> I do not much use it anyway. My job (both work and teaching, is C and
> OpenCL). What I was doing was to recommend it as next language to my
> students, when they ask about what OOP to learn (they had some
> choices, among C++ and Java). I find it very difficult to further
> recommend a language that I do not believe in. Well, I still have two
> weeks to think about that, semester ends on June 20 (exam of C).

Why were you considering recommending a programming language you have almost no
experience with anyways?
I would be grateful if you point out that it exists, but recommending it might
indeed be a bad idea.


Timon


More information about the Digitalmars-d mailing list