On 12/30/10 11:08 AM, Steven Schveighoffer wrote:
I'd have to see how it works. I also thought the new operator
overloading scheme was reasonable -- until I tried to use it.
You mean until you tried to use it /once/.
Note this is even more bloated because you generate one function per
pair of types used in concatenation, vs. one function per class defined.
That function is inlined and vanishes out of existence. I wish one day
we'd characterize this bloating issue more precisely. Right now anything
generic has the "bloated!!" alarm stuck to it indiscriminately.
How do you mean bloated? For documentation you specify in the
documentation of the type what operators it supports, or for each
named method you specify that operator xxx forwards to it.
I mean bloated because you are generating template functions that just
forward to other functions. Those functions are compiled in and take up
space, even if they are inlined out.
I think we can safely leave this matter to compiler technology.
Let's also realize that the mixin is going to be required *per
interface* and *per class*, meaning even more bloat.
The bloating argument is a complete red herring in this case. I do agree
that generally it could be a concern and I also agree that the compiler
needs to be improved in that regard. But by and large I think we can
calmly and safely think that a simple short function is not a source of
worry.
I agree if there is a "standard" way of forwarding with a library mixin,
the documentation will be reasonable, since readers should be able to
get used to looking for the 'atlernative' operators.
Whew :o).
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.
Not at all. The common case is shorter and simpler. I wrote the
chapter on operator overloading twice, once for the old scheme and
once for the new one. It uses commonly-encountered designs for its
code samples. The chapter and its code samples got considerably
shorter in the second version. You can't blow your one example into an
epic disaster.
The case for overloading a single operator is shorter and simpler with
the old method:
auto opAdd(Foo other)
vs.
auto opBinary(string op)(Foo other) if (op == "+")
Where the new scheme wins in brevity (for written code at least, and
certainly not simpler to understand) is cases where:
1. inheritance is not used
2. you can consolidate many overloads into one function.
So the question is, how many times does one define operator overloading
on a multitude of operators *with the same code* vs. how many times does
one define a few operators or defines the operators with different code?
In my experience, I have not yet defined a type that uses a multitude of
operators with the same code. In fact, I have only defined the "~=" and
"~" operators for the most part.
Based on extensive experience with operator overloading in C++ and on
having read related code in other languages, I can firmly say both of
(1) and (2) are the overwhelmingly common case.
So I'd say, while my example is not proof that this is a disaster, I
think it shows the change in operator overloading cannot yet be declared
a success. One good example does not prove anything just like one bad
example does not prove anything.
Many good examples do prove a ton though. Just off the top of my head:
- complex numbers
- checked integers
- checked floating point numbers
- ranged/constrained numbers
- big int
- big float
- matrices and vectors
- dimensional analysis (SI units)
- rational numbers
- fixed-point numbers
If I agree with something is that opCat is an oddity here as it doesn't
usually group with others. Probably it would have helped if opCat would
have been left named (just like opEquals or opCmp) but then uniformity
has its advantages too. I don't think it's a disaster one way or
another, but I do understand how opCat in particular is annoying to your
case.
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 very strongly believe the new operator overloading is a vast
improvement over the existing one and over most of today's languages.
I haven't had that experience. This is just me talking. Maybe others
believe it is good.
I agree that the flexibility is good, I really think it should have that
kind of flexibility. Especially when we start talking about the whole
opAddAssign mess that was in D1. It also allows making wrapper types
easier.
The problem with flexibility is that it comes with complexity. Most
programmers looking to understand how to overload operators in D are
going to be daunted by having to use both templates and template
constraints, and possibly mixins.
Most programmers looking to understand how to overload operators in D
will need to bundle them (see the common case argument above) and will
go with the TDPL examples, which are clear, short, simple, and useful.
There once was a discussion on how to improve operators on the phobos
mailing list (don't have the history, because i think it was on
erdani.com). Essentially, the two things were:
1) let's make it possible to easily specify template constraints for
typed parameters (such as string) like this:
auto opBinary("+")(Foo other)
which would look far less complex and verbose than the current
incarnation. And simple to define when all you need is one or two
operators.
I don't see this slight syntactic special case a net improvement over
what we have.
2) make template instantiations that provably evaluate to a single
instance virtual. Or have a way to designate they should be virtual.
e.g. the above operator syntax can only have one instantiation.
This may be worth exploring, but since template constraints are
arbitrary expressions I fear it will become a mess of special cases
designed to avoid the Turing tarpit.
We shouldn't discount all of its advantages and focus exclusively on
covariance, which is a rather obscure facility.
I respectfully disagree. Covariance is very important when using class
hierarchies, because to have something that returns itself degrade into
a basic interface is very cumbersome. I'd say dcollections would be
quite clunky if it weren't for covariance (not just for operator
overloads). It feels along the same lines as inout -- where inout allows
you to continue using your same type with the same constancy, covariance
allows you to continue to use the most derived type that you have.
Okay, I understand.
Using operator overloading in conjunction with class inheritance is rare.
I don't use operator overloads and class inheritance, but I do use
operator overloads with interfaces. I think rare is not the right term,
it's somewhat infrequent, but chances are if you do a lot of interfaces,
you will encounter it at least once. It certainly doesn't dominate the
API being defined.
Maybe a more appropriate characterization is that you use catenation
with interfaces.
Rare as it is, we need to allow it and make it convenient. I believe
this is eminently possible along the lines discussed in this thread.
Convenience is good. I hope we can do it at a lower exe footprint cost
than what you have proposed.
We need to destroy Walter over that code bloating thing :o).
As a compromise, can we work on a way to forward covariance, or to have
the compiler reevaluate the template in more derived types?
I understand. I've had this lure a few times, too. The concern there
is that this is a potentially surprising change.
Actually, the functionality almost exists in template this parameters.
At least, the reevaluation part is working. However, you still must
incur a performance penalty to cast to the derived type, plus the
template nature of it adds unnecessary bloat.
Saw that. I have a suspicion that we'll see a solid solution from you soon!
Andrei
