On Mon, Nov 23, 2009 at 4:27 AM, Steven Schveighoffer <schvei...@yahoo.com> wrote: > On Fri, 20 Nov 2009 19:32:10 -0500, Bill Baxter <wbax...@gmail.com> wrote: > >> On Fri, Nov 20, 2009 at 4:22 PM, Justin Johansson <n...@spam.com> wrote: >>> >>> Bill Baxter wrote: >>>> >>>> On Fri, Nov 20, 2009 at 3:36 PM, Walter Bright >>>> <newshou...@digitalmars.com> wrote: >>>>> >>>>> And here I was thinking perhaps opApply should just be dumped in favor >>>>> of >>>>> ranges. >>>>> >>>> >>>> I think the opApply should take precedence. >>>> The only reason to define opApply is because foreach uses it. >>>> Ranges on the other hand are useful in other situations. >>>> >>>> --bb >>> >>> Is is absolutely necessary for opApply to take a ref parameter? (I'm >>> asking >>> from D1 familiarity not D2 so question might not be relevant). >>> >>> My understanding is that by taking a ref parameter there is an additional >>> pointer dereference to get to the actual datum that is the subject of >>> current application. Of course the current regime does appear to allow a >>> foreach to modify the items in the "container" being iterated over, >>> though >>> myself, I've only ever used foreach in readonly mode. >> >> Making the delegate's arg "const ref" seems to work in D2. >> And prevents writing to the argument, as expected. > > It still requires an lvalue, which is not always convenient... > > I have proposed an enhancement for this, see > http://d.puremagic.com/issues/show_bug.cgi?id=2443
Yeh, that enhancement request makes total sense. I was certainly baffled by the inability to use a non-ref type there, too. --bb