custom attribute proposal (yeah, another one)

Marco Leise Marco.Leise at gmx.de
Mon Apr 9 07:36:50 PDT 2012


Am Mon, 09 Apr 2012 09:13:51 -0400
schrieb "Steven Schveighoffer" <schveiguy at yahoo.com>:

> On Sat, 07 Apr 2012 10:00:19 -0400, Jacob Carlborg <doob at me.com> wrote:
> 
> > On 2012-04-06 19:37, Steven Schveighoffer wrote:
> >> On Fri, 06 Apr 2012 12:53:51 -0400, Piotr Szturmaj
> >>> struct Author { string name = "empty"; }
> >>> // struct Author { string name; } - this works too
> >>
> >> I think the point is, we should disallow:
> >>
> >> @Author int x;
> >>
> >> -Steve
> >
> > Why?
> 
> I misspoke.  The person who implemented the @Author attribute probably  
> wants to disallow specifying an Author attribute without a name.  I don't  
> think we should disallow that on principle, I meant in the context it  
> should be disallowed.
> 
> -Steve

Yes, when libraries start to offer attributes, their authors likely want to add some static checking. Either as an invariant() with the struct solution, or static asserts in the function.

Java and C# also offer attributes for attributes to:
- allow multiple attributes of the same kind on a symbol
- restrict the attribute to certain symbol types (function, struct, ...)
- inherit attributes down a class hierarchy
I thought I'd just mention it all here in one go as "attribute constraints".

-- 
Marco



More information about the Digitalmars-d mailing list