Making them not virtual would also make them not overridable, they'd all be implicitly final.

Is there any compelling use case for virtual operator overloads? Keep in mind that any non-virtual function can still be a wrapper for another virtual method, so it is still possible (with a bit of extra work) for a class to have virtual operator overloads. It just wouldn't be the default.

On Sat, 28 Nov 2009 02:32:21 +0300, Walter Bright <newshound1@digitalmars.com> wrote:

> Making them not virtual would also make them not overridable, they'd all be implicitly final.
>
> Is there any compelling use case for virtual operator overloads? Keep in mind that any non-virtual function can still be a wrapper for another virtual method, so it is still possible (with a bit of extra work) for a class to have virtual operator overloads. It just wouldn't be the default.

I thought operator overloading was going to be implemented via templates. As such, they are non-virtual by default, which is okay, in my opinion.

== Quote from Walter Bright (newshound1@digitalmars.com)'s article
> Making them not virtual would also make them not overridable, they'd all
> be implicitly final.
> Is there any compelling use case for virtual operator overloads? Keep in
> mind that any non-virtual function can still be a wrapper for another
> virtual method, so it is still possible (with a bit of extra work) for a
> class to have virtual operator overloads. It just wouldn't be the default.

What would making them non-virtual accomplish?  I don't think making them non-virtual would hurt too much in practice, but it would introduce an inconsistency into the language relative to "regular" methods.  Therefore, I don't think it should be done without a very good reason.

Fri, 27 Nov 2009 15:32:21 -0800, Walter Bright wrote:

> Making them not virtual would also make them not overridable, they'd all be implicitly final.
> 
> Is there any compelling use case for virtual operator overloads? Keep in mind that any non-virtual function can still be a wrapper for another virtual method, so it is still possible (with a bit of extra work) for a class to have virtual operator overloads. It just wouldn't be the default.

Is this again one of those features that is supposed to hide the fact that dmd & optlink toolchain sucks? At least gcc can optimize the calls in most cases where the operator is defined to be virtual, but is used in non-polymorphic manner.

== Quote from retard (re@tard.com.invalid)'s article
> Fri, 27 Nov 2009 15:32:21 -0800, Walter Bright wrote:
> > Making them not virtual would also make them not overridable, they'd all be implicitly final.
> >
> > Is there any compelling use case for virtual operator overloads? Keep in mind that any non-virtual function can still be a wrapper for another virtual method, so it is still possible (with a bit of extra work) for a class to have virtual operator overloads. It just wouldn't be the default.
> Is this again one of those features that is supposed to hide the fact that dmd & optlink toolchain sucks? At least gcc can optimize the calls in most cases where the operator is defined to be virtual, but is used in non-polymorphic manner.

If so, I think it's a bad idea.

1.  Eventually, we will get a better optimizer.  GDC has been resurrected, and after D2 is finalized and all of the more severe bugs are fixed, hopefully Walter will have some time to focus on performance issues.

2.  This optimization can trivially be done manually by declaring the overloads final.  What would we gain by introducing the inconsistency with "normal" methods?

On Fri, 27 Nov 2009 22:58:00 -0500, retard <re@tard.com.invalid> wrote:

> Fri, 27 Nov 2009 15:32:21 -0800, Walter Bright wrote:
>
>> Making them not virtual would also make them not overridable, they'd all
>> be implicitly final.
>>
>> Is there any compelling use case for virtual operator overloads? Keep in
>> mind that any non-virtual function can still be a wrapper for another
>> virtual method, so it is still possible (with a bit of extra work) for a
>> class to have virtual operator overloads. It just wouldn't be the
>> default.
>
> Is this again one of those features that is supposed to hide the fact
> that dmd & optlink toolchain sucks? At least gcc can optimize the calls
> in most cases where the operator is defined to be virtual, but is used in
> non-polymorphic manner.

Yes and no. Yes, DMD doesn't have link time optimization (LTO), which is what enables this. No, because LTO can't do this optimization in many cases, such as creating/using a DLL/shared object. (Static libraries might also have some issues, but I'm not sure.)

dsimcha:
> but it would introduce an
> inconsistency into the language relative to "regular" methods.

Right, it's an exception to a rule of the language, so it increases the language complexity.

Bye,
bearophile

== Quote from retard (re@tard.com.invalid)'s article
> Sat, 28 Nov 2009 08:16:33 -0500, bearophile wrote:
> > dsimcha:
> >> but it would introduce an
> >> inconsistency into the language relative to "regular" methods.
> >
> > Right, it's an exception to a rule of the language, so it increases the language complexity.
> I guess the systems programming language users more often think that 'more executable bloat when compiled with the currently available practical real world tools, the more complex the language in practical real world use'. So if there's some tiny little feature that saves you 1-2 cpu cycles in practical real world systems programming applications or makes building a practical real world non-academic commercial compiler a bit easier and thus provides more practical value to the paying customer, the language should include that feature.

Ok, well then how does making operator overloads implicitly final improve over being consistent with the rest of the language and making them explicitly final if you want them final?

Note:  I'm not against making overloading non-virtual if it's implemented with templates, because this is non-arbitrary and consistent with the rest of the language.  I'm only against it if it's done arbitrarily by treating operator overload functions as "special" in this regard.

Denis Koroskin wrote:
> I thought operator overloading was going to be implemented via templates. As such, they are non-virtual by default, which is okay, in my opinion.

Yes, that's the rationale. I'm looking for a hole in it.

retard wrote:
> Is this again one of those features that is supposed to hide the fact that dmd & optlink toolchain sucks? At least gcc can optimize the calls in most cases where the operator is defined to be virtual, but is used in non-polymorphic manner.

The gnu linker (ld) does not do any optimizations of virtual call => direct call. Optlink has nothing to do with it.

  struct C {
    virtual int foo() { return 3; }
  };

  void bar(C* c) {
    c->foo();   <== no virtual call optimization here (1)
  }

  int main() {
    C* c = new C();
    c->foo();   <== virtual call optimization here (2)
    bar(c);
    return 0;
  }

What D doesn't do is (2). What D does do, and C++ does not, is allow one to specify a class is final or a method is final, and then both (1) and (2) will be optimized to direct calls.

Doing (2) is entirely a function of the front end, not the linker.