Le 07/11/2012 05:19, Walter Bright a écrit :
On 11/6/2012 7:52 PM, bearophile wrote:
Walter Bright:
But I'm not sure at this point if that is the right thing to do.
Why?
D was fortunate in having 10 years of experience with C++'s exception
system to learn from. We don't have that with UDAs.
[If you decide to restrict UDAs, then later it will be easy to extend
them, it
will not break code. While doing the opposite break code. It's you the
one that
has taught me to design things this way :-) ]
It's a good point, but I have no experience with UDAs. There may be
emergent behavior with these features that is completely unexpected, and
we wouldn't find out about it without having it there.
I don't think that is a good idea. As attribute as they are defined
agglomerate in a tuple, without correct typing, it is impossible to
determine for a piece of code which attributes belongs to the current
processing or not.
For instance, let say that I'm writing a lib using attributes. I expect
int attribute to be attached to a symbol and does some processing on it.
If another dev of another lib decide to do the same, then it is is now
impossible to use both libs together.
Unless we decide up front, by convention, what an int attribute means.
But even in this case, it is risky. As my experience shown in the past,
using convention to ensure certain property in the some code usually fail.
Yes, I know it's a risk.
(And it was a no-brainer to restrict the exception types. But one must
be careful in drawing analogies in programming, as different things are,
well, different and can be different in unexpected, surprising ways.)
