On 4/6/2012 1:15 AM, Alex Rønne Petersen wrote:
On 06-04-2012 09:54, Walter Bright wrote:
On 4/6/2012 12:49 AM, Alex Rønne Petersen wrote:
What about type declarations? I think those ought to be supported too.
E.g. it
makes sense to mark an entire type as @attr(serializable) (or the
inverse).


That would make it a "type constructor", not a storage class, which we
talked about earlier in the thread. I refer you to that discussion.

To be clear, I don't want annotations on a type declaration to actually affect
the type. Annotations are just that: Annotations. Nothing else.

What would an annotation on a type mean if it does not affect the type? Would it just be baggage carried along? If so, how would that affect types inside of a template, where the type was passed as a type constructor? How would type inference work? Would an alias carry or drop the baggage? How would overloading work? How would covariance work? It's a maze of complex decisions.


Does a design like that still give rise to the semantic issues you mentioned (it
isn't clear what those are)?

Yes.

(I know Java does this. But Java has a trivial type system compared with D. It doesn't even have type aliases. It doesn't have type constructors. Etc.)

Reply via email to