On 12/30/10 1:17 PM, Steven Schveighoffer wrote:
On Thu, 30 Dec 2010 12:52:32 -0500, Andrei Alexandrescu
<[email protected]> wrote:
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.
Functions inline out of existence during runtime, but the function
itself remains resident in the compiled binary.
Doesn't have to!
I don't know that it's an important aspect to keep it in there or not, I
just know it's kept. There are a whole slew of improvements we can make
in this regard, but I'm not sure they are possible, because I'm not a
compiler writer.
Please take my word for it: this is a solved problem.
One such nuisance in particular is the proliferation of types when you
use something like isInputRange. That invariably is *only* used at
compile time, yet the type and its typeinfo are injected into the binary.
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.
I hope that can be done. D already suffers from the 'hey what gives, how
come hello world is 1MB?!!' syndrome.
More like 600KB, but yah :o). Note that the size of the executable is
caused by other issues, compared to which the concerns at hand are puny.
[snip]
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
One more:
- Variant types
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.
Probably the most common operator overload in D is opEquals, luckily
that is not a template (even though it sadly does not work with
interfaces yet).
It seems that operator overloads are in categories. There are the
numeric overloads, which I agree are generally overloaded in groups.
When I defined cursors to be more like C++ iterators in dcollections
instead of small ranges, I used the ++ and -- overloads, which you
typically define together.
When designing the mixin that allows you to define various operator
overloads, I think it would be hugely beneficial to take into account
these groupings and make the mixins modular.
That's a valuable insight! Introspection can help a lot, e.g. you can
synthesize opAdd from opAddAssign (or vice versa) etc.
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.
The code itself is simple, it's the "how does x + y match up with this
template thingy" which is the problem I think. We've already had several
posts on d.learn ask how operator overloads work even after reading TDPL.
I'm not worried about this most at all as I think (unintentionally)
things have fallen in the right place: operator overloading is an
advanced, specialized topic. I believe the set of users who are
sophisticated enough to sit down and start overloading operators at
large, yet at the same time are beginners enough to not grasp the notion
of a generic function in D (which is much simpler than in other
languages) may as well be not empty, but is small enough to not cater for.
Saw that. I have a suspicion that we'll see a solid solution from you
soon!
Alas, no solution is possible without templates being allowed in
interfaces :( But yes, I plan to use this technique as soon as it's
possible.
I voted for it now, too. As I always use all of my 10 votes, I had asked
on the Phobos list to increase that limit, but was thoroughly shredded
into little pieces.
Andrei
