www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - __traits(getAttributes, ...) gets attributes for the first overload

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Working on the big-oh thing I noticed that for an overloaded function, 
__traits(getAttributes, ...) applied to overloaded functions only 
fetches attributes for the first syntactically present overload. Bug or 
feature?

Andrei
Dec 05 2015
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 5 December 2015 at 20:44:40 UTC, Andrei Alexandrescu 
wrote:
 Working on the big-oh thing I noticed that for an overloaded 
 function, __traits(getAttributes, ...) applied to overloaded 
 functions only fetches attributes for the first syntactically 
 present overload. Bug or feature?
Did you use it in a loop with __traits(getOverloads) too? Borrowing from the doc example: import std.stdio; class D { this() { } ~this() { } ("test") void foo() { } (12) int foo(int) { return 2; } } void main() { D d = new D(); foreach (t; __traits(getOverloads, D, "foo")) { // the getAttributes here inside the getOverloads // loop will cause it to get specific writeln(__traits(getAttributes, t)); writeln(typeid(typeof(t))); } }
Dec 05 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/05/2015 04:30 PM, Adam D. Ruppe wrote:
 On Saturday, 5 December 2015 at 20:44:40 UTC, Andrei Alexandrescu wrote:
 Working on the big-oh thing I noticed that for an overloaded function,
 __traits(getAttributes, ...) applied to overloaded functions only
 fetches attributes for the first syntactically present overload. Bug
 or feature?
Did you use it in a loop with __traits(getOverloads) too? Borrowing from the doc example:
[snip] Thanks, the code is easy to fix but my question is in regard to a potential bug. -- Andrei
Dec 05 2015
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 12/5/15 5:42 PM, Andrei Alexandrescu wrote:
 On 12/05/2015 04:30 PM, Adam D. Ruppe wrote:
 On Saturday, 5 December 2015 at 20:44:40 UTC, Andrei Alexandrescu wrote:
 Working on the big-oh thing I noticed that for an overloaded function,
 __traits(getAttributes, ...) applied to overloaded functions only
 fetches attributes for the first syntactically present overload. Bug
 or feature?
Did you use it in a loop with __traits(getOverloads) too? Borrowing from the doc example:
[snip] Thanks, the code is easy to fix but my question is in regard to a potential bug. -- Andrei
What is the behavior you would expect? It's somewhat consistent with taking the delegate of an overloaded function. -Steve
Dec 05 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/5/15 6:04 PM, Steven Schveighoffer wrote:
 On 12/5/15 5:42 PM, Andrei Alexandrescu wrote:
 On 12/05/2015 04:30 PM, Adam D. Ruppe wrote:
 On Saturday, 5 December 2015 at 20:44:40 UTC, Andrei Alexandrescu wrote:
 Working on the big-oh thing I noticed that for an overloaded function,
 __traits(getAttributes, ...) applied to overloaded functions only
 fetches attributes for the first syntactically present overload. Bug
 or feature?
Did you use it in a loop with __traits(getOverloads) too? Borrowing from the doc example:
[snip] Thanks, the code is easy to fix but my question is in regard to a potential bug. -- Andrei
What is the behavior you would expect?
Error.
 It's somewhat consistent with taking the delegate of an overloaded
 function.
It was my thinking that in D order of declarations shouldn't ever matter. -- Andrei
Dec 05 2015
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 12/5/15 6:07 PM, Andrei Alexandrescu wrote:
 On 12/5/15 6:04 PM, Steven Schveighoffer wrote:
 On 12/5/15 5:42 PM, Andrei Alexandrescu wrote:
 On 12/05/2015 04:30 PM, Adam D. Ruppe wrote:
 On Saturday, 5 December 2015 at 20:44:40 UTC, Andrei Alexandrescu
 wrote:
 Working on the big-oh thing I noticed that for an overloaded function,
 __traits(getAttributes, ...) applied to overloaded functions only
 fetches attributes for the first syntactically present overload. Bug
 or feature?
Did you use it in a loop with __traits(getOverloads) too? Borrowing from the doc example:
[snip] Thanks, the code is easy to fix but my question is in regard to a potential bug. -- Andrei
What is the behavior you would expect?
Error.
 It's somewhat consistent with taking the delegate of an overloaded
 function.
It was my thinking that in D order of declarations shouldn't ever matter. -- Andrei
It makes sense that it should be an error in both cases. But what happens to existing code is always the eternal question... -Steve
Dec 05 2015
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/5/2015 2:42 PM, Andrei Alexandrescu wrote:
 Thanks, the code is easy to fix but my question is in regard to a potential
bug.
https://www.youtube.com/watch?v=34ag4nkSh7Q&feature=player_detailpage#t=27
Dec 07 2015
prev sibling parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Saturday, 5 December 2015 at 20:44:40 UTC, Andrei Alexandrescu 
wrote:
 Working on the big-oh thing I noticed that for an overloaded 
 function, __traits(getAttributes, ...) applied to overloaded 
 functions only fetches attributes for the first syntactically 
 present overload. Bug or feature?

 Andrei
In an ideal world I would want it to be an error to use __traits(getAttributes, ...) on anything ambiguous, would catch the odd bug. The current behaviour is dumb, but some union of attributes over the overload sets seems worse.
Dec 05 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/5/15 7:41 PM, John Colvin wrote:
 On Saturday, 5 December 2015 at 20:44:40 UTC, Andrei Alexandrescu wrote:
 Working on the big-oh thing I noticed that for an overloaded function,
 __traits(getAttributes, ...) applied to overloaded functions only
 fetches attributes for the first syntactically present overload. Bug
 or feature?

 Andrei
In an ideal world I would want it to be an error to use __traits(getAttributes, ...) on anything ambiguous, would catch the odd bug. The current behaviour is dumb, but some union of attributes over the overload sets seems worse.
Yah, error is the way to go. -- Andrei
Dec 05 2015
next sibling parent Jack Stouffer <jack jackstouffer.com> writes:
On Sunday, 6 December 2015 at 02:00:30 UTC, Andrei Alexandrescu 
wrote:
 Yah, error is the way to go. -- Andrei
https://issues.dlang.org/show_bug.cgi?id=15414
Dec 06 2015
prev sibling next sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Sunday, 6 December 2015 at 02:00:30 UTC, Andrei Alexandrescu 
wrote:
 On 12/5/15 7:41 PM, John Colvin wrote:
 On Saturday, 5 December 2015 at 20:44:40 UTC, Andrei 
 Alexandrescu wrote:
 Working on the big-oh thing I noticed that for an overloaded 
 function,
 __traits(getAttributes, ...) applied to overloaded functions 
 only
 fetches attributes for the first syntactically present 
 overload. Bug
 or feature?

 Andrei
In an ideal world I would want it to be an error to use __traits(getAttributes, ...) on anything ambiguous, would catch the odd bug. The current behaviour is dumb, but some union of attributes over the overload sets seems worse.
Yah, error is the way to go. -- Andrei
The potential problem I see with this idea is that adding an overload to an otherwise non-overloaded function might break some code elsewhere which queries the function's attributes. In other circumstances, adding an unambiguous overload is never a breaking change, right?
Dec 06 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/06/2015 08:13 PM, Vladimir Panteleev wrote:
 On Sunday, 6 December 2015 at 02:00:30 UTC, Andrei Alexandrescu wrote:
 On 12/5/15 7:41 PM, John Colvin wrote:
 On Saturday, 5 December 2015 at 20:44:40 UTC, Andrei Alexandrescu wrote:
 Working on the big-oh thing I noticed that for an overloaded function,
 __traits(getAttributes, ...) applied to overloaded functions only
 fetches attributes for the first syntactically present overload. Bug
 or feature?

 Andrei
In an ideal world I would want it to be an error to use __traits(getAttributes, ...) on anything ambiguous, would catch the odd bug. The current behaviour is dumb, but some union of attributes over the overload sets seems worse.
Yah, error is the way to go. -- Andrei
The potential problem I see with this idea is that adding an overload to an otherwise non-overloaded function might break some code elsewhere which queries the function's attributes. In other circumstances, adding an unambiguous overload is never a breaking change, right?
Well what if you add it before the existing function? -- Andrei
Dec 06 2015
prev sibling parent reply NX <nightmarex1337 hotmail.com> writes:
On Sunday, 6 December 2015 at 02:00:30 UTC, Andrei Alexandrescu 
wrote:
 Yah, error is the way to go. -- Andrei
Can I ask a question?: Why we don't have a way to get an exact overload of function? Something like: void foo(int i); int foo(float f); //... int function(float) foop = &foo::(float);
Dec 07 2015
parent Jakob Ovrum <jakobovrum gmail.com> writes:
On Monday, 7 December 2015 at 23:52:38 UTC, NX wrote:
 On Sunday, 6 December 2015 at 02:00:30 UTC, Andrei Alexandrescu 
 wrote:
 Yah, error is the way to go. -- Andrei
Can I ask a question?: Why we don't have a way to get an exact overload of function? Something like: void foo(int i); int foo(float f); //... int function(float) foop = &foo::(float);
`&foo` is a special "type" that will implicitly convert to both `void function(int)` and `int function(float)`. No special syntax is needed, just trigger the conversion.
Dec 07 2015