On 11/06/2012 05:41 PM, Walter Bright wrote:
> On 11/6/2012 8:23 AM, bearophile wrote:
>> Supporting annotations for function arguments is probably an important
>> sub-feature.
>
> It would be a significant extension, and so I'd like to see a compelling
> use case first.
> ...

The use cases are the same as for other declarations. Parameter declarations are not special.

On 11/06/2012 06:31 PM, deadalnix wrote:
> Le 06/11/2012 18:14, Walter Bright a écrit :
>> On 11/6/2012 9:00 AM, dennis luehring wrote:
>>> 1. what if my needs are beyond D?
>>>
>>> for example my idl allows me to define a type based query source for
>>> parameters
>>>
>>> CalculateStuff( TypeX [source="\\placement\(typeA|typeB|typeC)"]
>>> my_usage )
>>>
>>> this defines the source of assignable objects to this method
>>
>> Has this capability ever been used?
>>
>>
>>> 2. what is the reason for stopping right before parameters? (except
>>> less coding
>>> on your side)
>>
>> It adds significant complexity. I don't think it's a good idea to add
>> significant complexity to the language without a compelling use case. It
>> needs to be something more than just being nice.
>>
>
> It remove complexity in the sens it remove special cases.
>
> It indeed add complexity for the compiler.

But almost none. It is easy to get right.

On Tuesday, 6 November 2012 at 20:14:56 UTC, Walter Bright wrote:
> On 11/6/2012 11:42 AM, Max Samukha wrote:> Theoretically there might be cases requiring an attribute of the same class both
> > on the function and on the return value. Then differentiation
> of function and
> > return value attributes would be necessary. Anybody has an
> example?
>
> Not a problem, as you'd search the tuple for the attribute that matters anyway.

By "the same class" I meant:

template SomeFunkyID(string id)
{
}

[SomeFunkyID!"boo"]
[return: SomeFunkyID!"bar"]
void foo();

In C#, I can distinguish, which of SomeFunkyID instances is intended for the return value and which for the function itself. How would I do that if both attributes were piled together in the same tuple?

On Tuesday, 6 November 2012 at 17:20:10 UTC, Walter Bright wrote:
> On 11/6/2012 9:07 AM, John Chapman wrote:
>> UDAs appear to work on class, struct and global methods, but not interface
>> methods. Any reason for the omission? Would be great to have them on interface
>> methods too - for example to define COM dispids.
>
> Can you show an example code snippet?

It would save having to read the registry and load type libraries at runtime just to map method names to corresponding IDs.

struct dispid {
  int value;
}

// WebBrowser event interface to be implemented
interface DWebBrowserEvents2 : IDispatch {
  [dispid(102)] void statusTextChange();
  [dispid(108)] void progressChange();
  [dispid(105)] void commandStateChange();
  /* and so on */
}

Then the implementing class maps method names to IDs.

mixin template COMDispatch() {
  int[string] dispIdMap;
  void delegate()[int] methodMap;
  this() {
    // Use __traits to get member names and dispid attributes
    // from base interfaces and store in dispIdMap.
    // Then connect up IDs to delegates in methodMap.
    foreach (T; InterfacesTuple!(typeof(this)))
      foreach (m; __traits(getMembers, T))
        methodMap[dispIdMap[m]] = &mixin(m);
  }
  HRESULT GetDispIDsOfNames(wchar** names, int count, int* ids) {
    // A COM component asks for IDs of our methods.
    foreach (i; 0 .. count) {
      ids[i] = dispIdMap.get(names[i].toString(), DISPID_UNKNOWN);
    }
  }
  HRESULT Invoke(int dispId) {
    // A COM component calls Invoke, and we forward to a method.
    if (auto m = dispId in methodMap) m();
  }
}

class WebBrowserEventsImpl : DWebBrowserEvents2 {
  mixin COMDispatch;

  void statusTextChange() {}
  void progressChange() {}
  void commandStateChange() {}
}

On 11/06/2012 07:02 PM, Walter Bright wrote:
> On 11/6/2012 9:34 AM, dennis luehring wrote:
>> can't you please give us a bad-usage example why it is/should be
>> forbidden to
>> use UDA on parameters (and please - we are not talking about pure, in,
>> out and
>> stuff like that)
>
> I believe this is the wrong question. For a new feature, the question
> should be "why should it be included", not "why shouldn't it be included."
> ...

The same holds for arbitrary restrictions.

I thought the general agreement was to include the feature.
Language features should be as general and as orthogonal as possible and reasonable.

On 11/6/2012 12:33 PM, John Chapman wrote:
> On Tuesday, 6 November 2012 at 17:20:10 UTC, Walter Bright wrote:
>> On 11/6/2012 9:07 AM, John Chapman wrote:
>>> UDAs appear to work on class, struct and global methods, but not interface
>>> methods. Any reason for the omission? Would be great to have them on interface
>>> methods too - for example to define COM dispids.
>>
>> Can you show an example code snippet?
>
> It would save having to read the registry and load type libraries at runtime
> just to map method names to corresponding IDs.

I could use a compilable one :-)

Yes, I could edit it until it was compilable, but often that makes the problem go away and then there's more back and forth.

On 11/6/2012 12:28 PM, Max Samukha wrote:
> In C#, I can distinguish, which of SomeFunkyID instances is intended for the
> return value and which for the function itself. How would I do that if both
> attributes were piled together in the same tuple?

Make SomeFunkyID a parameter to a ReturnOnly template that you've defined.

On Tuesday, 6 November 2012 at 17:20:10 UTC, Walter Bright wrote:
> On 11/6/2012 9:07 AM, John Chapman wrote:
>> UDAs appear to work on class, struct and global methods, but not interface
>> methods. Any reason for the omission? Would be great to have them on interface
>> methods too - for example to define COM dispids.
>
> Can you show an example code snippet?

For further examples on how annotations on interfaces would be useful, see my post about Thrift – services happen to be translated into D interfaces.

David

On Tuesday, 6 November 2012 at 20:41:27 UTC, Timon Gehr wrote:
> On 11/06/2012 07:02 PM, Walter Bright wrote:
>> On 11/6/2012 9:34 AM, dennis luehring wrote:
>>> can't you please give us a bad-usage example why it is/should be
>>> forbidden to
>>> use UDA on parameters (and please - we are not talking about pure, in,
>>> out and
>>> stuff like that)
>>
>> I believe this is the wrong question. For a new feature, the question
>> should be "why should it be included", not "why shouldn't it be included."
>> ...
>
> The same holds for arbitrary restrictions.
>
> I thought the general agreement was to include the feature.
> Language features should be as general and as orthogonal as possible and reasonable.

Exactly. Looking forward to complaints about impossibility to annotate module declarations.

Just thinking out loud...

##################################################
[Controller("thing")]
[VirtualAction("new", "create", Protect(Role("admin")))]
[VirtualAction("edit", "update", Protect(OwnerRelation))]
class ThingController : ApplicationController {

    [Action, Protect(Role("admin"))]
    void create ( Request req, Response res ) {...}

    [Action]
    void index ( Request req, Response res ) {...}

    [Action, Protect(Role("member"))]
    void show ( Request req, Response res ) {...}

    [Action, Protect(OwnerRelation)]
    void update ( Request req, Response res ) {...}

    [Action("delete"), Protect(Role("admin"))]
    void remove ( Request req, Response res ) {...}

}


[Model("thing")]
[ForbidMassAssignment]
class Thing : Model {

    [Attr, Shallow]
    [Validate( Present, Unique, Length("<=", 128) )]
    A!string name;

    [Attr, Shallow]
    [Validate( Length("[]", 16, 256) )]
    A!string description;

    [Attr(BelongsTo, User), Shallow]
    [Validate( Present )]
    A!User user;

    [Attr(HasMany, Tag, Through(Tagging))]
    [Validate( NoDuplicate )]
    A!(Tagging[]) tags;

    [Attr]
    [Validate( Present )]
    A!ulong size;

    [Attr]
    [Validate( Present )]
    A!ulong weight;

    @property
    ulong ratio () {...}

}
##################################################

My mind reels...

-- Chris Nicholson-Sauls