2012/9/1 Dmitry Olshansky <dmitry.o...@gmail.com>:
> 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.
>
This reminds me custom attributes discussion which can be found in NG archive.
Requested language additions relevant to attributes may be divided
into three groups:
1 (tags). We want to tag some (likely function) declarations like
@nogc. This addition has several issues:
- can tags carry additional information (for e.x @tag(atrr1=opened))?
- are they part of type or not (similar problems with default arguments)?
- are they user-defined or entirely built in the language?
- how to distinguish between restricted and permissive semantic (when
tagged function care about
whether they call non-tagged functions or not)?
In this case possible solutions are to link user-defined enumeration
types to existing @syntax
or to create entirely new syntax for purpose of holding additional
information (@tag(atrr1=opened)
where @attr1 refers to enum attr1{} ). Simply tagged functions
(@tag(name)) would have restrictive
semantics. Another possible solution would be that construction
"@tag(attr1=value) type symbol;" is rewritten as
struct __name {type symbol; enum att1 = value; alias type this; } -
just not to add brand new features
which are hard to implement and easy to introduce bugs.
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.
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.
Obviously this can be done only in run-time
where actual instance of type is created.
In this case possible solutions are to put associative array or some
container in druntime (object.Object) which export
attributes for e.x. through .attributeof property.
I offer simple solutions because I estimate probability of introducing
complex addition to the language now as
extremely low.
