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