Clay language

Michel Fortin michel.fortin at michelf.com
Thu Dec 30 09:37:49 PST 2010


On 2010-12-30 11:02:43 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

> On 12/30/10 9:22 AM, Michel Fortin wrote:
>> On 2010-12-30 10:00:05 -0500, "Steven Schveighoffer"
>> <schveiguy at 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.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/



More information about the Digitalmars-d mailing list