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

[Timothee Cour]

On Mon, Jun 24, 2013 at 11:46 PM, monarch_dodra <monarchdodra at gmail.com>wrote:

> On Monday, 24 June 2013 at 22:27:19 UTC, Brad Anderson wrote:
>
>> On Sunday, 23 June 2013 at 01:34:53 UTC, Andrei Alexandrescu wrote:
>>
>>> On 6/22/13 2:58 PM, monarch_dodra wrote:
>>>
>>>> long story short: we don't have rfind. C++ does.
>>>>
>>>
>>> We do, just that it's for random-access ranges. C++ offers it for
>>> bidirectional ranges too. We could of course support it if bidirectional
>>> ranges were required to have something like r1.before(r2) that, assuming r2
>>> is reachable from r1, returns the portion in r1 that's before r2.
>>>
>>> Andrei
>>>
>>
>> How efficiently could before() be implemented?
>>
>
> In terms of efficiency, it would really depend on the range that
> implements it, but I'd say "o(1)": cheap. The problems are (imo):
> *defining the exact semantics that go with it.
> *defining the traits that go with it.
>
> One big hurdle (I think), is that there is no way to provide a default
> implementation, even for RA ranges with slicing. And that's very bad.
>
> I'm going to get bashed for this, but I think the concept of "iterable"
> range would be a much simpler concept: Far be for me to want iterators as
> the norm (puke), but being able to temporarily view a range (if possible),
> as two end points, before re-creating the range from said points, has some
> very simple, and easy to understand, yet efficient, semantics.
>
> It's really the only way to provide slicing for ranges that aren't RA...
>
> Eg:
> Range r;
> Range r10 = Range(r.begin, advance(r.begin, 10));
>

That seems possible in some cases, but not all.

the primitives for iterators should be roughly:
void iterator.popFront() (or ++)
bool iterator.equals(Iterator other);
auto iterator.front();

The tricky part is to define
bool iterator.equals(Iterator other);

there are cases where this is possible:
* range defined over an array
* range over elements assumed to be unique (interesting case)

but I don't see how that would work in general.
thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130625/24e71937/attachment.html>