Counter-Proposal: restrict & tagged functions

[Maxim Fomin]

On Monday, 3 September 2012 at 00:01:09 UTC, foobar wrote:
>> 2 (extending type). We want to define type (likely classes) 
>> and then
>> extend its functionality.
>> AFAIK C# attributes belong to this camp (correct me if I am 
>> wrong). In
>> this case (likely class) type implicitly derives
>> from attribute class. Obviously this also related to compile 
>> time
>> because D being static typed language and has no
>> way to be aware at run time that type functionality was 
>> extended. I
>> think that it is not worth embedding in the language, because
>> it is already possible to derive from base class, or 
>> interface, or
>> instantiated template or to use mixin.
>
> This is my preferred solution. This is also similar to Java. In 
> fact there are only small differences between C# and Java 
> semantics. This also includes other languages on the matching 
> platforms, E.g. Nemerle is a .net language and provides the 
> same attributes mechanism as C#. I assume that Scala does the 
> same with Java annotations.
>
> The C# way (which I slightly prefer over the Java one):
> class Whatever : Annotation { // user defined annotation type
> }
>
> Java uses @interface to define a user defined annotation.
> @interface whatever { // user defined annotation type
> }
>
> I don't get your last point at all regarding inheritance - in 
> both Java and C# it should be possible to use polymorphism with 
> annotations. No need to add a new mechanism for it.
> class Foo : whatever {} // inheritance
>
> Really, the main things that are needed inside the compiler are 
> a mechanism to attach custom attributes to various lingual 
> parts, a way to mark such custom attributes by e.g. deriving 
> from a special class (not unlike the IUnknown interface in D 
> for COM) and standard compiler APIs for usage inside such an 
> attribute.
> One extra step is defining an execution model for custom 
> attributes:
> Java way is multi-pass - compiler executes the annotations 
> which generate new version of the code, which is run through 
> the compiler again, and so forth.
> Nemerle way - attributes can be macros which in turn can 
> manipulate the AST.
> etc..
>

The question with this approach is follows: if attributes are 
just another way of deriving why not use old syntax?

>>
>> 3 (extending instance). We want to make some instance of 
>> (extremely likely class) type to extend functionality
>> while still remaining in original type without affecting type.
>
> I don't get this at all. What's the purpose of having a single 
> type?
>

It is not a single type, it is extending functionality of 
instance at run time which can be simulated by containers.