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

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)));
    }
}

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

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

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

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

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.

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

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

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?