On 12/30/10 11:37 AM, Michel Fortin wrote:
On 2010-12-30 11:02:43 -0500, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> said:
On 12/30/10 9:22 AM, Michel Fortin wrote:
On 2010-12-30 10:00:05 -0500, "Steven Schveighoffer"
<schvei...@yahoo.com> said:
The thing I find ironic is that with the original operator overloading
scheme, the issue was that for types that define multiple operator
overloads in a similar fashion, forcing you to repeat boilerplate
code. The solution to it was a mixin similar to what you are
suggesting. Except now, even mundane and common operator overloads
require verbose template definitions (possibly with mixins), and it's
the uncommon case that benefits. So really, we haven't made any
progress (mixins are still required, except now they will be more
common). I think this is one area where D has gotten decidedly worse.
I mean, just look at the difference above between defining the opcat
operator in D1 and your mixin solution!
I'm with you, I preferred the old design.
This is water under the bridge now, but I am definitely interested.
What are the reasons for which you find the old design better?
First it was simpler to understand. Second it worked well with inheritance.
The current design requires that you know of templates and template
constrains, and it requires complicated workarounds if you're dealing
with inheritance (as illustrated by this thread). Basically, we've made
a simple, easy to understand feature into an expert-only one.
And for what sakes? Sure the new design has the advantage that you can
define multiple operators in one go. But for all the cases where you
don't define operators to be the same variation on a theme, and even
more for those involving inheritance, it's more complicated now. And
defining multiple operators in one go wouldn't have been so hard with
the older regime either. All you needed was a mixin to automatically
generate properly named functions for each operator the opBinary
template can instantiate.
I was always skeptical of this new syntax, and this hasn't changed.
Thanks for the feedback. So let me make sure I understand your
arguments. First, you mention that the old design is simpler. Second,
you mention that the old design worked better with inheritance and with
cases in which each operator needs a separate definition.
I partially (only to a small extent) agree with the first and I disagree
with the second. (Overall my opinion that the new design is a vast
improvement hasn't changed.) But I didn't ask for your opinion to
challenge or debate it - thanks again for taking the time to share.
Andrei
