digitalmars.D - __traits(getAttributes, ...) gets attributes for the first overload
- Andrei Alexandrescu (5/5) Dec 05 2015 Working on the big-oh thing I noticed that for an overloaded function,
- Adam D. Ruppe (22/26) Dec 05 2015 Did you use it in a loop with __traits(getOverloads) too?
- Andrei Alexandrescu (4/11) Dec 05 2015 [snip]
- Steven Schveighoffer (4/17) Dec 05 2015 What is the behavior you would expect?
- Andrei Alexandrescu (4/22) Dec 05 2015 It was my thinking that in D order of declarations shouldn't ever
- Steven Schveighoffer (4/28) Dec 05 2015 It makes sense that it should be an error in both cases. But what
- Walter Bright (2/3) Dec 07 2015 https://www.youtube.com/watch?v=34ag4nkSh7Q&feature=player_detailpage#t=...
- John Colvin (6/11) Dec 05 2015 In an ideal world I would want it to be an error to use
- Andrei Alexandrescu (2/13) Dec 05 2015 Yah, error is the way to go. -- Andrei
- Jack Stouffer (3/4) Dec 06 2015 https://issues.dlang.org/show_bug.cgi?id=15414
- Vladimir Panteleev (7/27) Dec 06 2015 The potential problem I see with this idea is that adding an
- Andrei Alexandrescu (2/22) Dec 06 2015 Well what if you add it before the existing function? -- Andrei
- NX (9/10) Dec 07 2015 Can I ask a question?:
- Jakob Ovrum (4/14) Dec 07 2015 `&foo` is a special "type" that will implicitly convert to both
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
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
On 12/05/2015 04:30 PM, Adam D. Ruppe wrote:On Saturday, 5 December 2015 at 20:44:40 UTC, Andrei Alexandrescu wrote:[snip] Thanks, the code is easy to fix but my question is in regard to a potential bug. -- AndreiWorking 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:
Dec 05 2015
On 12/5/15 5:42 PM, Andrei Alexandrescu wrote:On 12/05/2015 04:30 PM, Adam D. Ruppe wrote:What is the behavior you would expect? It's somewhat consistent with taking the delegate of an overloaded function. -SteveOn Saturday, 5 December 2015 at 20:44:40 UTC, Andrei Alexandrescu wrote:[snip] Thanks, the code is easy to fix but my question is in regard to a potential bug. -- AndreiWorking 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:
Dec 05 2015
On 12/5/15 6:04 PM, Steven Schveighoffer wrote:On 12/5/15 5:42 PM, Andrei Alexandrescu wrote:Error.On 12/05/2015 04:30 PM, Adam D. Ruppe wrote:What is the behavior you would expect?On Saturday, 5 December 2015 at 20:44:40 UTC, Andrei Alexandrescu wrote:[snip] Thanks, the code is easy to fix but my question is in regard to a potential bug. -- AndreiWorking 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: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
On 12/5/15 6:07 PM, Andrei Alexandrescu wrote:On 12/5/15 6:04 PM, Steven Schveighoffer wrote:It makes sense that it should be an error in both cases. But what happens to existing code is always the eternal question... -SteveOn 12/5/15 5:42 PM, Andrei Alexandrescu wrote:Error.On 12/05/2015 04:30 PM, Adam D. Ruppe wrote:What is the behavior you would expect?On Saturday, 5 December 2015 at 20:44:40 UTC, Andrei Alexandrescu wrote:[snip] Thanks, the code is easy to fix but my question is in regard to a potential bug. -- AndreiWorking 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: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
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
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? AndreiIn 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
On 12/5/15 7:41 PM, John Colvin wrote:On Saturday, 5 December 2015 at 20:44:40 UTC, Andrei Alexandrescu wrote:Yah, error is the way to go. -- AndreiWorking 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? AndreiIn 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
On Sunday, 6 December 2015 at 02:00:30 UTC, Andrei Alexandrescu wrote:Yah, error is the way to go. -- Andreihttps://issues.dlang.org/show_bug.cgi?id=15414
Dec 06 2015
On Sunday, 6 December 2015 at 02:00:30 UTC, Andrei Alexandrescu wrote:On 12/5/15 7:41 PM, John Colvin wrote: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?On Saturday, 5 December 2015 at 20:44:40 UTC, Andrei Alexandrescu wrote:Yah, error is the way to go. -- AndreiWorking 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? AndreiIn 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 06 2015
On 12/06/2015 08:13 PM, Vladimir Panteleev wrote:On Sunday, 6 December 2015 at 02:00:30 UTC, Andrei Alexandrescu wrote:Well what if you add it before the existing function? -- AndreiOn 12/5/15 7:41 PM, John Colvin wrote: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?On Saturday, 5 December 2015 at 20:44:40 UTC, Andrei Alexandrescu wrote:Yah, error is the way to go. -- AndreiWorking 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? AndreiIn 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 06 2015
On Sunday, 6 December 2015 at 02:00:30 UTC, Andrei Alexandrescu wrote:Yah, error is the way to go. -- AndreiCan 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
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:`&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.Yah, error is the way to go. -- AndreiCan 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