What features of D are you using now which you thought you'd never goint to use?

Jonathan M Davis jmdavisProg at gmx.com
Tue Jun 25 21:14:29 PDT 2013


On Sunday, June 23, 2013 07:47:16 Andrei Alexandrescu wrote:
> On 6/23/13 7:39 AM, Andrei Alexandrescu wrote:
> > Again, we can make things work by introducing a primitive for
> > bidirectional ranges:
> > 
> > R before(R r1, R r2);
> > 
> > Assuming r2 is reachable from r1, returns the portion of r1 that lies
> > before r2. (Definition: a range r2 is reachable from another range r1 if
> > calling r1.popFront() repeatedly will at some point make r1.front and
> > r2.front refer to the same value.)
> 
> The question is, should we add this primitive? There's discussion on
> adding ranges to C++, and discussion inevitably reaches an impasse when
> it gets to this particular matter.
> 
> I personally think we should and am amazed that we made it so far
> without that primitive. However, unlike others, I don't think it's an
> essential matter. Some C++ people tend to be apprehensive when they
> figure they can do something with iterators that's not doable with ranges.

I think that we should be very leery of any case where iterators can do more 
than ranges. That doesn't necessarily mean that when we find something that 
iterators can do that ranges can't that we should add something new to ranges, 
but I think that when we find such cases, we should look at them very closely 
and figure out the best way to work around the problem and how critical a 
problem it is. There's also a definite cost to adding new range primitives, so 
I don't think that we want to jump the gun in favor of either adding or not 
adding new range primitives in order to overcome deficiencies in comparison to 
iterators.

Unfortunately, I never got around to reading the rfind discussion, so I don't 
know the details on that (I really should go back and read it), but not being 
able to do rfind is a major negative IMHO. Bidirectional ranges in general 
suffer when it comes to doing stuff with their back end, and I think that that 
becomes particularly clear when doing stuff with containers. So, we may really 
want to look at what we can do to improve support for stuff on the back end of 
ranges without having to add a whole lot of new stuff to do it. However, I'll 
have to study up on the suggested before primitive before I can really comment 
on whether that particular primitive is something that we should add or not.

Regardless, I think that we would do well to play around more with ranges and 
std.container in order to determine where the std.container API is weak with 
regards to ranges. In some cases, that probably means improving the API. In 
others, it may entail looking closer at whether we need to make any 
adjustments to the range primitives. Hopefully, we can make everything work 
well with little to no adjustments to the range API itself, but thus far, 
containers appear to be one area where iterators are actually considerably 
better than ranges (at least when it comes to using the iterator or range with 
the container's functions rather than simply iterating over the elements or 
passing the iterators or ranges to functions unrelated to the container).

- Jonathan M Davis


More information about the Digitalmars-d mailing list