On Wednesday, March 14, 2012 01:36:40 Alex Rønne Petersen wrote: > On 14-03-2012 01:18, Jonathan M Davis wrote: > > On Wednesday, March 14, 2012 01:14:04 Alex Rønne Petersen wrote: > >> On 14-03-2012 01:10, Jonathan M Davis wrote: > >>> On Tuesday, March 13, 2012 22:03:45 Alex Rønne Petersen wrote: > >>>> Did you see my other post? Maybe we could do something like this: > >>>> > >>>> equals_t opEquals()(const auto ref SysTime rhs) const pure nothrow > >>> > >>> That would probably work (though I wouldn't use equals_t, since it seems > >>> like an utterly pointless alias to me). Still, it shouldn't have to be > >>> templated to work with auto ref. > >>> > >>> - Jonathan M Davis > >> > >> That's arguable... > >> > >> The thing is, auto ref, when used on class methods cannot work. The > >> reason is simple: Inheritance. An overriding method can't magically take > >> both a value and a reference. > >> > >> Obviously we can special-case auto ref on structs, but... is this really > >> desirable? > > > > As I understand it, auto ref is supposed to work with _any_ function. The > > _compiler_ decides whether it's best to use a ref or a value. That may > > mean > > that you actually get two of the same function. I don't know. I do know > > that Walter misunderstood what Andrei meant and made it a template thing > > when it wasn't supposed to be. Supposedly, he's going to fix it, but he > > hasn't yet. > > > > - Jonathan M Davis > > How would it ever work? One entry in a vtable can't point to two functions.
I don't know. I believe that Timon had an explanation for how auto ref is supposed to work that he posted in a discussion semi-recently, but I don't remember the details. Regardless, as I understand it, it _is_ possible to have a non-templated function which can take an argument by either ref or value at the compiler's discretion and that that's what auto ref is supposed to do. But I don't know the details. - Jonathan M Davis
