On 18 March 2012 03:48, Walter Bright <newshound2@digitalmars.com> wrote:

> On 3/17/2012 6:39 PM, Manu wrote:
>
>> I'm sure C# already answers all these questions. It has precisely the
>> same set
>> of issues associated.
>>
>
> C# doesn't have RAII, immutable, nor the notion of threadlocal/shared types.
>

C# has immutable. How does RAII cause a problem here?
The threadlocal/shared stuff shouldn't be a problem, since the attribute
instances are contained by the class its self, it just has the same
locality properties. Can you imagine a case where that would be problematic?

On 3/17/2012 7:04 PM, Manu wrote:
> On 18 March 2012 03:48, Walter Bright <newshound2@digitalmars.com
> <mailto:newshound2@digitalmars.com>> wrote:
>
>     On 3/17/2012 6:39 PM, Manu wrote:
>
>         I'm sure C# already answers all these questions. It has precisely the
>         same set
>         of issues associated.
>
>
>     C# doesn't have RAII, immutable, nor the notion of threadlocal/shared types.
>
>
> C# has immutable.

No, it does not.

> How does RAII cause a problem here?

Generally, supporting it tends to permeate the semantics of the language. Simple things like copying a value onto the parameter stack entail all kinds of issues.

> The threadlocal/shared stuff shouldn't be a problem, since the attribute
> instances are contained by the class its self, it just has the same locality
> properties. Can you imagine a case where that would be problematic?

If it's shared, how is access to the data controlled if multiple threads access it at the same time?

On Sunday, 18 March 2012 at 01:48:07 UTC, Walter Bright wrote:
> On 3/17/2012 6:39 PM, Manu wrote:
>> I'm sure C# already answers all these questions. It has precisely the same set
>> of issues associated.
>
> C# doesn't have RAII, immutable, nor the notion of threadlocal/shared types.

It has threadlocal using the [ThreadLocal] attribute which gets implemented by the compiler.

In C#, all attributes live inside the TypeInfo/MethodInfo/etc for the class/struct/method/field/parameter. I don't see this being a problem. I can't think of good use cases where an attribute/annotation should be per-instance at all, particularly with the compile-time power that D has, whereas C# does not have any. Honestly, most uses of attributes in D would be done at compile-time, and I think that's acceptable until/if runtime reflection is put in. If it is needed, it can live inside TypeInfo/MethodInfo, but is (imo) absolutely not needed on a per-instance basis. This is the job of fields or interfaces.

On 3/17/2012 8:04 PM, Kapps wrote:
> It has threadlocal using the [ThreadLocal] attribute which gets implemented by
> the compiler.

That's a storage class, not a type constructor. In D, threadlocal/shared is a difference in the type.

> In C#, all attributes live inside the TypeInfo/MethodInfo/etc for the
> class/struct/method/field/parameter. I don't see this being a problem. I can't
> think of good use cases where an attribute/annotation should be per-instance at
> all, particularly with the compile-time power that D has, whereas C# does not
> have any. Honestly, most uses of attributes in D would be done at compile-time,
> and I think that's acceptable until/if runtime reflection is put in. If it is
> needed, it can live inside TypeInfo/MethodInfo, but is (imo) absolutely not
> needed on a per-instance basis. This is the job of fields or interfaces.

I also do not get why per-instance attributes even exist, as I agree that's what fields are for.

Walter, how do you feel about the compile time
annotation list?

I looked at implementing it, and it is a little
more involved than I thought (mainly in changing
parse.c to treat @ things as more than just storage
classes), but still not terrible.

Walter Bright wrote:
> I also do not get why per-instance attributes even exist, as I agree that's what fields are for.

Attributes are per-type (type properties, methods, etc), not per-instance, and only accessible (in C#) through type reflection (to my knowledge). According to http://msdn.microsoft.com/en-us/library/z919e8tw(v=vs.80).aspx attribute objects aren't constructed until reflected upon. I think attributes in combination with D's templates would be very useful:

    @attribute class Cool
    {
        bool isCool;
        this(bool cool)
        {
            isCool = cool;
        }
    }

    class CoolClass(bool cool)
    {
        @CoolType(cool);
        int type;
    }

    void main()
    {
        auto cc = new CoolClass!true();
        if (cc.type@Cool.isCool) { // (new Cool(true)).isCool
            // Do something cool...
        }
    }

Or, if @attributes could be applied to *any* type (enums, structs, variables, etc..), we could write this more simply:

    @attribute bool isCool;

    class CoolClass(bool cool)
    {
        @isCool = cool;
        int type;
    }

    void main()
    {
        auto cc = new CoolClass!true();
        if (cc.type@isCool) { // true
            // Do something cool...
        }
    }

and of course, the compiler could make use of attribute metadata during codegen. Things like Garbage Collection and memory compaction attributes come to mind:

    class MemoryPool
    {
        @GC.DontScan void*[] pool;
        @Int.Fast int index; // replace stdint
    }

Also, aliasing could be possible:

   @Int.Fast alias int intf;
   @Int.Least alias int intl;

F i L wrote:
>     class CoolClass(bool cool)
>     {
>         @CoolType(cool);
>         int type;
>     }

typo **@Cool(cool);

plus, I think a better syntax for attributes might be to have an attribute keyword for definitions and only use "@" for application:

attribute struct CoolType { ... }
attribute bool isCool;

@CoolType @(isCool = true) string coolText;

On 3/17/2012 9:12 PM, F i L wrote:
> Walter Bright wrote:
>> I also do not get why per-instance attributes even exist, as I agree that's
>> what fields are for.
>
> Attributes are per-type (type properties, methods, etc), not per-instance, and
> only accessible (in C#) through type reflection (to my knowledge). According to
> http://msdn.microsoft.com/en-us/library/z919e8tw(v=vs.80).aspx attribute objects
> aren't constructed until reflected upon.

My impression is it is just obfuscation around a simple lazy initialization pattern.

While I can see the abstraction usefulness of compile time attribute metadata, I am having a hard time seeing what the gain is with runtime attributes over more traditional techniques.

Walter Bright wrote:
> My impression is it is just obfuscation around a simple lazy initialization pattern.
>
> While I can see the abstraction usefulness of compile time attribute metadata, I am having a hard time seeing what the gain is with runtime attributes over more traditional techniques.

I'm not sure exactly what you mean by runtime attributes. Do you mean the ability to reflect upon attributes at runtime? In that case, there's two  benefits I can think of over "traditional" member data: Instance memory (attributes are create at reflection), and reusable metadata packages (similar to how you might use mixin templates only with less noise and reflection capabilities).

On 3/17/2012 10:01 PM, F i L wrote:
> Walter Bright wrote:
>> My impression is it is just obfuscation around a simple lazy initialization
>> pattern.
>>
>> While I can see the abstraction usefulness of compile time attribute metadata,
>> I am having a hard time seeing what the gain is with runtime attributes over
>> more traditional techniques.
>
> I'm not sure exactly what you mean by runtime attributes. Do you mean the
> ability to reflect upon attributes at runtime?

I mean there is modifiable-at-runtime, instance-specific data.

> In that case, there's two
> benefits I can think of over "traditional" member data: Instance memory
> (attributes are create at reflection),

Lazy initialization is a standard pattern. No special language features are needed for it.

> and reusable metadata packages (similar
> to how you might use mixin templates only with less noise and reflection
> capabilities).

Sounds like a garden variety user-defined data type.

Again, I am just not seeing the leap in power with this. It's a mystery to me how a user defined "attribute class" is different in any way from a user defined class, and what advantage special syntax gives a standard pattern for lazy initialization, and why extra attribute fields can't be just, well, fields.