bug with std.range.zip? range with opEquals(const) const not allowed inside zip
Jens Mueller
jens.k.mueller at gmx.de
Sun Aug 26 05:47:38 PDT 2012
Jonathan M Davis wrote:
> On Saturday, August 25, 2012 21:58:12 timotheecour wrote:
> > is that a bug? should i file a bug report?
>
> I'd have to study it more to say, but std.algorithm doesn't play very nicely
> with const right now. More work needs to be done in that area, and stuff like
> enhancement# 8407 would help considerably. I'm pretty sure that there's at
> least one compiler bug making it really hard for some portions of it to be
> const correct at the moment as well, but I can't remember what it was right
> now (and I could remember incorrectly).
>
> Your problem here may or may not be related to that. But if you can't get zip
> to play nicely with your struct when it has the proper signatures for
> opEquals, then please report it.
>
> > what is the "standard " signature for opEquals ?
>
> If you're using const, it's two functions:
>
> bool opEquals(const S rhs} const {...}
> bool opEquals(const ref S rhs) const {...}
>
> If you're not using const or you want it to work without const, then you
> use/add
>
> bool opEquals(S rhs) { ... }
> bool opEquals(ref S rhs) {...}
>
> Hopefully, we sort out the ref situation one of these days so that only one
> function is needed (at least as long as using const is okay) rather than two,
> but for now, this is what we get.
What is the ref situation?
I thought ref is used as an optimization that allows passing lvalues
more efficiently whereas without ref is needed for rvalues.
Jens
More information about the Digitalmars-d
mailing list