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