Clay language

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Thu Dec 30 10:09:32 PST 2010


On 12/30/10 11:37 AM, Michel Fortin wrote:
> 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.

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


More information about the Digitalmars-d mailing list