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.)