Short list with things to finish for D2

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Thu Nov 19 08:46:45 PST 2009


grauzone wrote:
> Andrei Alexandrescu wrote:
>> Any more thoughts, please let them known. Again, this is the ideal 
>> time to contribute. But "meh, it's a hack" is difficult to discuss.
> 
> Well that's just like as if Bjarne Stroustrup would ask you: "What would 
> you have done in my place? This looked like the right thing to do at 
> this time!". And now we're working on a language that's supposed to 
> replace C++.

I'm not sure what you mean here.

> Partially I don't really know how opBinary is supposed to solve most 
> operator overloading problems (listed in DIP7). It just looks like a 
> stupid dispatch mechanism. It could be implemented by using CTFE and 
> mixins without compiler changes: just let a CTFE function generate a 
> dispatcher function for each opSomething to opBinary. Of course, if you 
> think operators are something that's forwarded to something else, it'd 
> be nicer if dmd would be doing this, because code gets shorter. So 
> opSomething gets ditched in favor of opBinary. But actually, the 
> functionality of opBinary can be provided as a template mixin or a CTFE 
> function in Phobos. At least then the user has a choice what to use.

Things could indeed be generated with a CTFE mixin, but first we'd need 
a hecatomb of names to be added: all floating-point comparison operators 
and all index-assign operators. With the proposed approach there is no 
more need to add all those names and have the users consult tables to 
know how they are named.

> (About the issue that you need to remember names for operator symbols: 
> you know C++ has a fabulous idea how to get around this...)

I think it's not as flexible a solution as passing a compile-time string 
because there is no way to actually use that token.

> Now what about unary operators?

opUnary.

> Or very specific stuff like opApply? 

opApply stays as it is.

> What's with opSomethingAssign (or "expr1[expr2] @= expr3" in general)? 
> opBinary doesn't seem to solve any of those.

opBinary does solve opIndex* morass because it only adds one function 
per category, not one function per operator. For example:

struct T {
     // op can be "=", "+=", "-=" etc.
     E opAssign(string op)(E rhs) { ... }
     // op can be "=", "+=", "-=" etc.
     E opIndexAssign(string op)(size_t i, E rhs) { ... }
}

This was one motivation: instead of defining a lot of small functions 
that have each a specific name, define one function for each category of 
operations and encode the operator name as its own token. I don't 
understand exactly what the problem is with that.

> Also, all this just goes 
> down to a generic "opOperator(char[] expression, T...)(T args)", where 
> expression is actually an expression involved with the object. It feels 
> like this leads to nothing.

We need something to work with. "looks like a stupid mechanism" and 
"feels" are not things that foster further dialog.

> And opBinary is a just a quite arbitrary 
> stop on that way to nothing. Just a hack to make code shorter for some 
> use cases.

opBinary is a binary operator, hardly something someone would pull out 
of a hat. I'm not sure what you mean to say here.

> One way of solving this issue about "extended operator overloading" 
> would be to introduce proper AST macros. An AST macro could match on a 
> leaf of an expression and replace it by custom code, and use this 
> mechanism to deal with stuff like "expr1[expr2] @= expr3" (and I don't 
> see how opBinary would solve this... encode the expression as a string? 
> fallback to naive code if opBinary fails to match?). At least that's 
> what I thought AST macros would be capable to do.

See above on how the proposed approach addresses RMW operations on indexes.

> Anyway, AST macros got ditched in favor of const/immutable, so that's 
> not an option.

That I agree with.


Andrei



More information about the Digitalmars-d mailing list