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.

On Monday, 3 September 2012 at 16:21:08 UTC, Maxim Fomin wrote:
>
> The question with this approach is follows: if attributes are just another way of deriving why not use old syntax?

I think you conflate two concepts - the custom attributes _themselves_ can use the old syntax for polymorphism and reuse. This is however completely orthogonal from the action of attaching a custom attribute to an object (function, variable, type, etc). This is close to AOP and cross cutting concerns.
an example (perhaps a bit convoluted, just to illustrate a point):
// I want to have all my logging related code in one place.
class Log : Attribute {}
// inheritance of attributes
class LegalLog : Log {} // for legal department
class DeveloperLog : Log {} // for developers

// usage
@LegalLog(params)
class Foo : Bar {}

@DeveloperLog(params)
class Goo : Foo {}

The idea is that all the specifics of logging are concentrated in one place and not spread throughout the application. Say I want to change logging file format, I can do it by simply changing the relevant attributes without touching the main business logic of my application. It make no sense in this scenario to derive my business object classes from the Logging classes.

On 03-Sep-12 16:32, Piotr Szturmaj wrote:
> Dmitry Olshansky wrote:
>> On 01-Sep-12 17:01, Adam D. Ruppe wrote:
>>> On Saturday, 1 September 2012 at 12:39:41 UTC, Dmitry Olshansky wrote:
>>>> I'd say
>>>> @nogc:
>>>> at the top and deal is sealed.
>>>
>>> BTW don't forget a @yesgc would be good to counter it. We need
>>> a way to turn off each attribute to use this pattern best.
>>
>> What I see with this @nogc proposal is that that problem it tries to
>> solve (and tool used to do so) is far more interesting and general.
>>
>> Namely the problem is to specify that some functions can call only
>> specific subset of functions and able to use only specific subset of
>> language features. It's more far reaching then just gc, one may want to
>> get @noblocking  or @async attribute to statically check e.g. that GUI
>> thread can't ever block.
>> (it would however require to identify API calls that don't block, not
>> possible on every OS, might entail some wrappers etc. but is very
>> desirable)
>
> [snip]
>
>> The idea in a nutshell:
>
> [snip]
>
> How the attribute inferring works in this proposal?

Interesting... and it seems like user-defined tags can't be inferred or that it would need more thought.

However restrictions can be inferred by observing which things which template instance does and the tags of functions it calls. It's exactly the same as now but every restriction out of a set (say @safe) now get inferred separately.

-- 
Olshansky Dmitry

On Saturday, 1 September 2012 at 00:40:23 UTC, Piotr Szturmaj wrote:
> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP18

How this nogc attribute will work with phobos and druntime?

Kagamin wrote:
> On Saturday, 1 September 2012 at 00:40:23 UTC, Piotr Szturmaj wrote:
>> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP18
>
> How this nogc attribute will work with phobos and druntime?

I don't know what do you mean exactly. Some of the phobos and druntime functions will certainly not work, but some will do. Also, I think that nogc/pure/nothrow should be inferred, so they can be used without marking so many functions.

On 2012-09-01, 18:20, Dmitry Olshansky wrote:

> The idea in a nutshell:
>
> - specify a way attach tags to function declarations (to "paint" functions)
>
> - allow specifying is-a relation between tags (supertags and subtags).
>
> - add restrict specification that allows user to enforce on a block of code the following:
> 	a) disallow use of certain language features
> 	b) allow(or disallow) calling function with specific tags
>
> - fit with existing world and provide clean migration path, specify defaults
>
> I claim that it's enough to implement pure/safe/trusted/nothrow/nogc and proposed nogc.


I'm sorry I have not gotten around to commenting on this before, but I
*really* like this proposal. As foobar has said, a general annotation
system would be real nice, but as far as I can see, it can be built on
top of this, at a later point.

Also, I cannot see that this has been turned into a proper DIP. :p

http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs

-- 
Simen