On Tuesday, November 28, 2017 18:24:27 Jacob Carlborg via Digitalmars-d wrote:
> On 2017-11-28 03:20, Michael V. Franklin wrote:
> > For those who might want to know, Walter has informed me that this change will require a DIP.
>
> That's unfortunate. It should be the opposite, a DIP on why enum members should not support attributes. It goes against consistency (turtles all the way down).

For better or worse, Walter and Andrei seem to have gotten into a mode where just about any language change which isn't an outright bug fix requires a DIP. And a lack of turtles all the way down someplace is not really a bug fix (especially since it's sometimes debatable as to whether it's desirable in a particular case or whether something actually qualifies as being an issue with turtles all the way down; it's not always clearcut). However, a lack of consistency _is_ often a good argument - particularly if it's a lack of turtles all the way down consistency; arguments along those lines are how we ended up with stuff like local imports. So, if it's really that clear that enums really should be allowed to have attributes, then the DIP will probably be accepted.

- Jonathan M Davis

On Tuesday, 28 November 2017 at 02:20:15 UTC, Michael V. Franklin wrote:
> On Sunday, 19 November 2017 at 13:35:13 UTC, Michael V. Franklin wrote:
>
>> What's the official word?  Does it require a DIP?
>
> For those who might want to know, Walter has informed me that this change will require a DIP.  I already  have two DIPs in the queue right now, so I wouldn't mind if someone else wrote it.
>
> But, absent any volunteers, I would welcome all of you to reply to this thread with some use cases where you might find UDAs or other attributes useful on enum members.  Deprecation and serialization have already been mentioned, but it'd be impossible for me to imagine all the different ways users might find this feature useful.
>
> Thanks,
> Mike

I'd be interested in working on a DIP like this Michael, but I also want to expand the scope to allowing UDAs on function arguments as well. We should have some solid use cases in mind; let's take this to private email.

On Tuesday, 28 November 2017 at 01:49:19 UTC, Jonathan M Davis wrote:
> On Tuesday, November 28, 2017 00:15:24 John via Digitalmars-d wrote:
>> On Monday, 27 November 2017 at 17:48:35 UTC, Andrei Alexandrescu
>>
>> wrote:
>> > Hi Mike, this forum is not an appropriate place for requesting official answers. We don't scan the forums looking for matters that need attention. Feel free to send email to Walter and myself, and that will get answered. Thanks! -- Andrei
>>
>> Someone seems to disagree with you in that regard. https://forum.dlang.org/post/ouqgln$1chr$1@digitalmars.com
>>
>> Not only did it get your attention but you didn't even bother addressing it!
>
> There is a definite difference between posting stuff in the newsgroup to get attention brought to something and posting in the newsgroup to get an official answer on something from Walter or Andrei.
>
> - Jonathan M Davis

Not really, they can post the official answer on the github issue, that was brought to their attention through the forums. Him asking for an official answer is kind of irrelevant. Something was being neglected, and attention has been brought to it.

On Tuesday, 28 November 2017 at 01:49:19 UTC, Jonathan M Davis wrote:

> There is a definite difference between posting stuff in the newsgroup to get attention brought to something and posting in the newsgroup to get an official answer on something from Walter or Andrei.

My question was on behalf of everyone, so that is why I posted it to the forum.  I think Andrei was just trying to say that such questions are likely to be overlooked on the forum, so it is best to send an e-mail.  And that's fine with me.

Mike

On Tuesday, 28 November 2017 at 19:38:44 UTC, Meta wrote:
> On Tuesday, 28 November 2017 at 02:20:15 UTC, Michael V. Franklin wrote:
>> On Sunday, 19 November 2017 at 13:35:13 UTC, Michael V. Franklin wrote:
>>
>>> What's the official word?  Does it require a DIP?
>>
>> For those who might want to know, Walter has informed me that this change will require a DIP.  I already  have two DIPs in the queue right now, so I wouldn't mind if someone else wrote it.
>>
>> But, absent any volunteers, I would welcome all of you to reply to this thread with some use cases where you might find UDAs or other attributes useful on enum members.  Deprecation and serialization have already been mentioned, but it'd be impossible for me to imagine all the different ways users might find this feature useful.
>>
>> Thanks,
>> Mike
>
> I'd be interested in working on a DIP like this Michael, but I also want to expand the scope to allowing UDAs on function arguments as well. We should have some solid use cases in mind; let's take this to private email.

UDAs for function arguments would be really awesome to have. Just imagine how nice the Vibe.d web routes would look like:

auto postUser(@body User user, @errors Errors errors)

Instead of:
@body("user")
@errorDisplay
auto postUsers(User _user, string  _error)



Or:

@path("/users/:id")
auto getUser(@urlParam string id, @queryParam int page, @auth User user)

Instead of:

@path("/users/:id")
@queryParam("page")
@before!authenticate("user")
auto getUsers(string _id, int page, User user)


(This is pseudo-syntax as I write this from my phone).

On Tuesday, 28 November 2017 at 19:38:44 UTC, Meta wrote:

> I'd be interested in working on a DIP like this Michael, but I also want to expand the scope to allowing UDAs on function arguments as well. We should have some solid use cases in mind; let's take this to private email.

I'm on IRC almost daily under the alias JinShil.

Feel free to take this DIP and run with it.  I don't know if I would be much help anyway as I personally don't have a use case for this feature; it just seems like an implementation oversight to me.  That's why I asked for others to submit use cases.

That being said, having just finished a recent MVC ASP.Net Core project, I realize Seb's web-routes would be an outstanding use case; I don't know why it didn't occur to me.  Just further evidence I may not be the right person to advocate for this feature.

ORM also occurred to me as a potential use case.

Mike

On 2017-11-29 13:53, Seb wrote:

> UDAs for function arguments would be really awesome to have. Just imagine how nice the Vibe.d web routes would look like:
> 
> auto postUser(@body User user, @errors Errors errors)
> 
> Instead of:
> @body("user")
> @errorDisplay
> auto postUsers(User _user, string  _error)
> 
> 
> 
> Or:
> 
> @path("/users/:id")
> auto getUser(@urlParam string id, @queryParam int page, @auth User user)
> 
> Instead of:
> 
> @path("/users/:id")
> @queryParam("page")
> @before!authenticate("user")
> auto getUsers(string _id, int page, User user)
> 
> 
> (This is pseudo-syntax as I write this from my phone).

Yeah, that would be nice. I had another use case in mind as well, for DStep. Clang supports nullability attributes [1] which could be translated to UDAs. They would do anything but would be more for documentation purpose. I guess external tools could be built to actually do something useful with the attributes. Example:

In C:

int fetch(int * _Nonnull ptr);

In D:

int fetch(@Nonnull int* ptr);


[1] https://clang.llvm.org/docs/AttributeReference.html#nullability-attributes

-- 
/Jacob Carlborg

On 11/29/2017 07:53 AM, Seb wrote:
> UDAs for function arguments would be really awesome to have.

They should be part of the same DIP. -- Andrei

On 29.11.2017 17:21, Andrei Alexandrescu wrote:
> On 11/29/2017 07:53 AM, Seb wrote:
>> UDAs for function arguments would be really awesome to have.
> 
> They should be part of the same DIP. -- Andrei

More generally, any declaration should ideally support UDAs.

One issue with UDAs on function arguments is that function types will then have embedded UDAs, so the DIP should specify how that works.

On 11/29/17 11:45 AM, Timon Gehr wrote:
> On 29.11.2017 17:21, Andrei Alexandrescu wrote:
>> On 11/29/2017 07:53 AM, Seb wrote:
>>> UDAs for function arguments would be really awesome to have.
>>
>> They should be part of the same DIP. -- Andrei
> 
> More generally, any declaration should ideally support UDAs.
> 
> One issue with UDAs on function arguments is that function types will then have embedded UDAs, so the DIP should specify how that works.

Wouldn't it work the same as this?

@("foo")
struct S
{

}

void main()
{
    import std.stdio;
    @("bar") S s1;
    S s2;
    writeln(__traits(getAttributes, s1));         // bar
    writeln(__traits(getAttributes, typeof(s1))); // foo
    writeln(__traits(getAttributes, s2));         // (nothing)
    writeln(__traits(getAttributes, typeof(s2))); // foo
}

-Steve