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