So, I wrote this beautiful BigO framework: <400 lines all told, clear code, real nice. Then I got this cold shower:

void insertFrontMany(C, R)(C container, R range)
    @BigO(complexity!(C.insertFront) * linearTime)
{
   ...
}

My hope being of course that for containers with linear insertion time at the front I'll get quadratic, etc. The hitch is:

test.d(377): Error: undefined identifier 'C.insertFront'

So... attributes are currently not allowed to depend on template parameters, which is a serious damper on enthusiasm.

Seems to me this is a bug - different instantiations should have different attributes etc. Is there any matter of principle making this not work?

If this won't work at all, I'll need to resort to expressing complexity via traits. Not as nice!


Thanks,

Andrei

On Wednesday, 16 December 2015 at 17:14:50 UTC, Andrei Alexandrescu wrote:
> So... attributes are currently not allowed to depend on template parameters, which is a serious damper on enthusiasm.

Indeed, please see the discussion in:
https://issues.dlang.org/show_bug.cgi?id=10193

/Daniel

On 12/16/2015 06:14 PM, Andrei Alexandrescu wrote:
> So, I wrote this beautiful BigO framework: <400 lines all told, clear
> code, real nice. Then I got this cold shower:
>
> void insertFrontMany(C, R)(C container, R range)
>      @BigO(complexity!(C.insertFront) * linearTime)
> {
>     ...
> }
>
> My hope being of course that for containers with linear insertion time
> at the front I'll get quadratic, etc.

linear and quadratic in what?

> The hitch is:
>
> test.d(377): Error: undefined identifier 'C.insertFront'
>
> So... attributes are currently not allowed to depend on template
> parameters,

Yes, they are.

template bar(T){ @(T.str) auto bar(T t){ } }

struct A{ enum str="str"; }
static assert(__traits(getAttributes,bar!A)[0]=="str");


> ...
>
> Seems to me this is a bug - different instantiations should have
> different attributes etc. Is there any matter of principle making this
> not work?
> ...

No, just a broken lowering in the parser.

auto bar(T)(T t)@(T.str){ }

should be the same as

template bar(T){ auto bar(T t)@(T.str){ } }

It's probably very easy to fix.

On 12/16/2015 06:46 PM, Daniel N wrote:
> On Wednesday, 16 December 2015 at 17:14:50 UTC, Andrei Alexandrescu wrote:
>> So... attributes are currently not allowed to depend on template
>> parameters, which is a serious damper on enthusiasm.
>
> Indeed, please see the discussion in:
> https://issues.dlang.org/show_bug.cgi?id=10193
>
> /Daniel

This is a slightly different issue. (The UDA is before the declaration there.)

On Wednesday, 16 December 2015 at 18:01:11 UTC, Timon Gehr wrote:
> On 12/16/2015 06:46 PM, Daniel N wrote:
>> On Wednesday, 16 December 2015 at 17:14:50 UTC, Andrei Alexandrescu wrote:
>>> So... attributes are currently not allowed to depend on template
>>> parameters, which is a serious damper on enthusiasm.
>>
>> Indeed, please see the discussion in:
>> https://issues.dlang.org/show_bug.cgi?id=10193
>>
>> /Daniel
>
> This is a slightly different issue. (The UDA is before the declaration there.)

I thought that it doesn't matter on which side you put the UDA. Just like pure nothow, etc. Why should there be any difference?

On 12/16/2015 12:14 PM, Andrei Alexandrescu wrote:
[snip]

I submitted https://issues.dlang.org/show_bug.cgi?id=15464, which is preapproved. There is a bit of a sense of urgency to it - it blocks the bigo library proposal and an article.

Takers?


Andrei

On Monday, 21 December 2015 at 13:58:53 UTC, Andrei Alexandrescu wrote:
> On 12/16/2015 12:14 PM, Andrei Alexandrescu wrote:
> [snip]
>
> I submitted https://issues.dlang.org/show_bug.cgi?id=15464, which is preapproved. There is a bit of a sense of urgency to it - it blocks the bigo library proposal and an article.
>
> Takers?
>
>
> Andrei

https://github.com/D-Programming-Language/dmd/pull/5314

On 17 December 2015 at 03:14, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> So, I wrote this beautiful BigO framework: <400 lines all told, clear code, real nice. Then I got this cold shower:
>
> void insertFrontMany(C, R)(C container, R range)
>     @BigO(complexity!(C.insertFront) * linearTime)
> {
>    ...
> }
>
> My hope being of course that for containers with linear insertion time at the front I'll get quadratic, etc. The hitch is:
>
> test.d(377): Error: undefined identifier 'C.insertFront'
>
> So... attributes are currently not allowed to depend on template parameters, which is a serious damper on enthusiasm.

Remember that time I complained about this more than 2 and a half years ago?

https://issues.dlang.org/show_bug.cgi?id=10193

> Seems to me this is a bug - different instantiations should have different attributes etc. Is there any matter of principle making this not work?

Seems like a bug to me too, since you can express it with a fully expanded template, just not with the template syntax you actually use.

On Wednesday, 16 December 2015 at 17:14:50 UTC, Andrei Alexandrescu wrote:
> So, I wrote this beautiful BigO framework: <400 lines all told, clear code, real nice. Then I got this cold shower:
>
> void insertFrontMany(C, R)(C container, R range)
>     @BigO(complexity!(C.insertFront) * linearTime)
> {
>    ...
> }
>
> My hope being of course that for containers with linear insertion time at the front I'll get quadratic, etc. The hitch is:
>
> test.d(377): Error: undefined identifier 'C.insertFront'
>
> So... attributes are currently not allowed to depend on template parameters, which is a serious damper on enthusiasm.
>
> Seems to me this is a bug - different instantiations should have different attributes etc. Is there any matter of principle making this not work?
>
> If this won't work at all, I'll need to resort to expressing complexity via traits. Not as nice!
>
>
> Thanks,
>
> Andrei

What you are asking the compiler here is ambiguous. It is not clear if the attribute apply to the template (in which case argument may not be used) or the instantiated eponymous function in it.

On Monday, 21 December 2015 at 13:58:53 UTC, Andrei Alexandrescu wrote:
> On 12/16/2015 12:14 PM, Andrei Alexandrescu wrote:
> [snip]
>
> I submitted https://issues.dlang.org/show_bug.cgi?id=15464, which is preapproved. There is a bit of a sense of urgency to it - it blocks the bigo library proposal and an article.
>
> Takers?
>
>
> Andrei

I think this is a bit pushed out of the door. What if I want to 'attribute' the template itself ?