2013/5/27 Jonathan M Davis <jmdavisProg@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.


> 2. super doesn't work with UFCS. Take this code for example
>

As Lionello already mentioned, this is not an issue.

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.

Kenji Hara

On Tuesday, May 28, 2013 12:39:45 Kenji Hara wrote:
> 2013/5/27 Jonathan M Davis <jmdavisProg@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