D - more or less power than C++?

[Kevin Bealer]

In article <ducnmj$rv$2 at digitaldaemon.com>, Walter Bright says...
>
>
>"Johan Granberg" <lijat.meREM at OVEgmail.com> wrote in message 
>news:dubpge$u3r$1 at digitaldaemon.com...
>>>> 1. const parameters and member functions
>>>> Countless times this saved me. I just can't imagine references being
>>>> passed in and out of functions without something explicitly saying that
>>>> the function is expected or not to modify it.
>> You did not answer the above statement and i have seen this repeated all 
>> over this thread along with destructors in structs.
>
>Because the const thing has been endlessly thrashed about in other threads.
>
>> I will not repeat all the arguments but to me this is important issues.
>> If i should rank the most showstoping things in D (from my perspective) it 
>> would be
>> 1. bugs
>> 2. as far as I know no way of inporting somthing in a parent directory (as 
>> C++ #include "../myheader.hpp")
>
>The -I compiler switch can specify the "root" from whence all the packages 
>derive.
>
>> 3. read only sematics that work as a strong reminder that one is not 
>> suposed to modify somthing (but can bee subverted by a cast)
>> 4. overlodable assignment and copy constructors.
>> 5. library and other minor issues
>>
>>>> 4. library
>>>> ...
>>> I don't find the STL compelling, either, and that's the only library 
>>> thing standard C++ has over libc. Furthermore, large chunks of STL are 
>>> simply irrelevant in D because D has core arrays, strings, and 
>>> associative arrays.
>>
>> I agree on this one. So wath is your plan for the D standard library?
>
>Keep incrementally improving it. Is there anything in particular you feel is 
>missing? 

One thing I miss a little is continuously sorted collections, as with a tree or
similar.  The primary reason is to add elements, print them in order, keep
adding, etc.

It seems like this could be done in D fairly simply, since associative arrays
(as I understand) already include a binary tree if the hash value fails.  So by
defining a hash foo.toHash() that returns the same for all elements, int[foo]
could be used as a tree.

The main thing missing would seem to be access to this - i.e. finding ranges
without iterating the entire collection.  As in lower_bound / upper_bound in C++
or some variant of foreach-like functionality.

foo[char[]] x;
x.useHash = false; // disables hashing - only valid on an empty array

foreach(char[] k, foo v; x) {
// print all elements in order
}

// advanced version - associative array slicing

foreach(char[] k, foo v; x["allen".."burns") {
// print all elements from allen up to (but not including) burns, in order
}

x.least // lowest key
x.most // highest key

x.least_gt("abc"); // least element greater than "abc"

x[x.least] // element with lowest key

x[x.least_gt("abc")] // first element with key >= "abc"

Kevin