DIP64: Attribute Cleanup

[Brian Schott via Digitalmars-d]

On Friday, 20 June 2014 at 19:48:49 UTC, H. S. Teoh via 
Digitalmars-d wrote:
> First, there is no way to mark a function as *impure* as 
> opposed to pure
> (leaving out "pure" is not an option in template functions due 
> to
> automatic attribute inference). Also, there's an inconsistency 
> between
> positive attributes (pure, safe) vs. negative attributes 
> (nothrow,
> nogc). So ideally, the new syntax should allow you to specify 
> both pure
> and impure, and ideally, it should not special-case on 
> peculiarities of
> the English language (pure/impure vs. throw/nothrow). So it 
> should be
> something like @pure, @!pure, @throw, @!throw, @gc, @!gc, etc., 
> for
> maximum consistency.

I can see this being useful. We'd just have to decide what it 
means to negate an attribute with arguments. (e.g. 
`@!name("bob")`)

Also in the case of @!throw we'd have to modify the definition of 
attributes to accept the "throw" token instead of just 
identifiers. Maybe converting "nothrow" to "@!throws" would be 
better.

> I also like your attribute sets idea. This could be the 
> solution we're
> looking for with transitive attributes (aka inout(pure), 
> inout(nothrow),
> etc.). If there was some syntax for attribute set intersection, 
> say
> @a*@b, then we could specify that the attribute set of some 
> given
> function f() is the intersection of the attribute sets of its 
> input
> delegates. For example:
>
> 	// This is hypothetical syntax, I'm sure you can think of a
> 	// better way to write this.
> 	int dgCaller(int delegate(int) @a dg1, int delegate(int) @b 
> dg2)
> 		@this = @a*@b // specifies that this function's
> 			      // attributes is the intersection of @a and @b
> 	{
> 		if (someCondition)
> 			return dg1(1);
> 		else
> 			return dg2(2);
> 	}
>
>
> T

Is that use case common enough to justify complicating the 
compiler?