Loyc.Collections.RangeEnumerator< R, T > Struct Template Reference

Helper struct: enumerates through a forward range (IFRange{T}), calling the range methods through R instead of through IFRange{T}. More...

---

Source file:

• /Core/Loyc.Interfaces/Concrete/RangeEnumerator.cs

Inheritance diagram for Loyc.Collections.RangeEnumerator< R, T >:

Remarks

Helper struct: enumerates through a forward range (IFRange{T}), calling the range methods through R instead of through IFRange{T}.

Type Constraints

R	:	IFRange<T>
R	:	ICloneable<R>

Public fields
R	_range
T	_current

Properties
T	Current [get]
object System.Collections.IEnumerator.	Current [get]

Public Member Functions
	RangeEnumerator (R range)
bool	MoveNext ()
void IDisposable.	Dispose ()
void System.Collections.IEnumerator.	Reset ()

Static Public Member Functions
static R_	R_Clone< R_ > (R_ r)
	Since R implements IFRange{T} which includes ICloneable{IFRange{T}}, we cannot invoke ICloneable{R}.Clone because the compiler complains that Clone() is ambiguous. I used to think it was necessary to cast the range to ICloneable{R} just to clone it; if R is a value type then it is boxed, hurting performance. But then I thought of doing this. More...

Member Function Documentation

static R_ Loyc.Collections.RangeEnumerator< R, T >.R_Clone< R_ > ( R_  r )

static

Since R implements IFRange{T} which includes ICloneable{IFRange{T}}, we cannot invoke ICloneable{R}.Clone because the compiler complains that Clone() is ambiguous. I used to think it was necessary to cast the range to ICloneable{R} just to clone it; if R is a value type then it is boxed, hurting performance. But then I thought of doing this.

Type Constraints

R_	:	ICloneable<R_>
R_	:	r.Clone()