A Fresh Look at Comparisons, Take 2

[Janice Caron]

On 18/04/2008, Yigal Chripun <yigal100 at gmail.com> wrote:
>  with the above suggestion the opCmp would accept the above "obj" ot type
>  B since it has static type A.
>  is the above behavior acceptable? I'm not sure.

Good question.

>  for example, what if my code retrieves A's from a collection, so by
>  comparing only number and not name it can retrieve the wrong instance
>  from the collection(a real example would be a collection of widgets in a
>  GUI toolkit representing all the controls of a screen). the compiler
>  cannot check this at compile time so in order to prevent this the check
>  should happen at run-time and an exception should be thrown on error.

Actually, I don't think that would be a problem, for the following
reason: the use of "explicit" would not be compulsory! So in the
circumstance you describe, you'd just define an opCmp, and /not/ make
it explicit. Then the normal rules of inheritance would apply.



>  D really needs a standard facility to add user defined annotations
>  (metadata) to code and instead of adding more keywords to D, the above
>  "explicit" would be a perfect candidate to be provided by the standard
>  library.

Since its purpose is to block inheritance, I'm not completely sure how
a library could do that. But I do agree with you about needing a
mechanism for such things. After all, we don't add a new keyword every
time we add a function, so why should we need a new keyword for each
new type-constructor or storage class? Someone else pointed out that
the @ sign is unused in D, and could be used for annotations ... but
that's an issue for another thread.