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