opApply and const

[Robert Fraser]

Bill Baxter wrote:
> I mentioned it in another thread but I just wanted to confirm it.
> Am I right in thinking that if we want to have user types act like 
> built-in containers w.r.t iteration in D2 then we need to implement 12 
> different versions of opApply?!
> 
> Namely:
> 
> // plain vanilla
> int opApply(int delegate(ref T)) {...}
> const int opApply(int delegate(ref const T)) {...}
> invariant int opApply(int delegate(ref invariant T)) {...}
> 
> // with counter
> int opApply(int delegate(ref size_t, ref T)) {...}
> const int opApply(int delegate(ref size_t, ref const T)) {...}
> invariant int opApply(int delegate(ref size_t, ref invariant T)) {...}
> 
> // backwards
> int opApplyReverse(int delegate(ref T)) {...}
> const int opApplyReverse(int delegate(ref const T)) {...}
> invariant int opApplyReverse(int delegate(ref invariant T)) {...}
> 
> // backwards with counter
> int opApplyReverse(int delegate(ref size_t, ref T)) {...}
> const int opApplyReverse(int delegate(ref size_t, ref const T)) {...}
> invariant int opApplyReverse(int delegate(ref size_t, ref invariant T)) 
> {...}
> 
> That's a lot of opApply!  I was already mildly annoyed by the four 
> needed without const.  But with both const (and invariant) it just seems 
> downright silly.
> 
> --bb

It's not just opApply; any function would need to be written three times 
for accessing constant data in a possibly mutable class.