Transition for removing functions from Object [Compiler devs in particular, please read]

[Jonathan M Davis]

On Tuesday, May 28, 2013 12:39:45 Kenji Hara wrote:
> 2013/5/27 Jonathan M Davis <jmdavisProg at gmx.com>
> 
> > 1. You can't do UFCS with overloaded operators, and opEquals and opCmp are
> > overloaded operators. In general, I think that it would be bad to be able
> > to
> > overload operators via UFCS (especially with functions that are as core as
> > opEquals and opCmp), but if we could at least make it so that the compiler
> > allowed it in this case until the deprecation process has been completed,
> > then
> > these functions could be UFCS-able.
> 
> Class objects and '==' (equality operation) is already treated specially.
> Even if a class object has opEquals method (currently Object class has
> opEquals, so it's always true), equality operation c1 == c2 is always
> forwarded to object.opEquals(c1, c2). As well we can also forward
> comparison operator to object.opCmp specially.

That seems like a good approach.

> 3. The override keyword makes it so that making those functions free
> 
> > functions
> > will break all code everywhere that uses them. override is fantastic for
> > catching changes in class hierarchies so that you can fix your code when
> > base
> > classes change, but it does not give us a good deprecation path. So, if we
> > were to make these functions free functions, the compiler would have to be
> > adjusted so that in this particular case, it gave a message about it (and
> > not
> > a warning, as that would cause code to break with -w) rather than giving
> > an
> > error. I do think that this _should_ give an error normally, as you'd no
> > longer be overriding anything, but we need to be able to not make it an
> > error
> > in this case if we want a smooth transition. override is intended for
> > catching
> > bugs quite loudly and not for smooth deprecation paths.
> 
> In this case, compiler should stop reporting "does not override any
> function" error.
> If -w switch is on, the redundant override keyword usage would be warned.

If we can do that, that would be great. With opCmp acting like opEquals, and 
override temporarily being altered for them, we could remove them from Object 
and make them free functions in object_.d, which would start us on the path of 
getting this major issue resolved.

For better or worse though, it definitely looks like the key missing pieces are 
going to have to be done by the compiler devs. I'd love to get the ball 
rolling on this, but I don't know enough about the compiler to do it.

- Jonathan M Davis