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

monarch_dodra monarchdodra at gmail.com
Sun Jun 23 02:54:55 PDT 2013


On Sunday, 23 June 2013 at 09:44:09 UTC, Vladimir Panteleev wrote:
> On Sunday, 23 June 2013 at 09:10:03 UTC, monarch_dodra wrote:
>> All of these will *iterate* over part of said range, but none 
>> will actually return the subrange I iterated on.
>
> `until` does not iterate, it simply returns a range which ends 
> when your condition is satisfied.

"Lazily iterates range until value sentinel is found, at which 
point it stops."

>>        V
>> [ .  .  X  .  .  .  .  .  .  .  . ]
>>
>> I want:
>> [ .  .  X ]
>
> Isn't this what `until` does?

Not quite, it returns an object that returns those items when 
iterated on. But it is not the same type.

>> countUntil + take can kind of mitigate the problem, but that 
>> warps the type system: The type of take is not the type of the 
>> range.
>
> I believe wrapper ranges like `take` return ranges with the 
> same capabilities as the ranges they wrap. This modularity 
> design assumes that you will use the result in functions that 
> accept ranges, i.e. templated functions that expect that the 
> types of their parameters satisfy the is*Range constraints.

Same capabilities, different types.

> To avoid misunderstanding or miscommunication, could you post 
> the practical problem you encountered, with context?

The problem always boils down the fact that while we can get the 
same iteration scheme, it's never the same range type:

Range r = some_range;
r = r.until!"a == 5"; //Does not compile Until!Range and Range do 
not match
r = r.take(5); //Does not compile: Take!Range and Range do not 
match



More information about the Digitalmars-d mailing list