Jump to page: 1 2
Thread overview
[Issue 16410] attribute inference for final methods of templated classes
[Issue 16410] attribute inference inside templated classes
Aug 21, 2016
Lodovico Giaretta
Aug 21, 2016
b2.temp@gmx.com
Aug 21, 2016
Lodovico Giaretta
Aug 21, 2016
b2.temp@gmx.com
Aug 21, 2016
Lodovico Giaretta
Aug 21, 2016
b2.temp@gmx.com
Aug 23, 2016
Lodovico Giaretta
Aug 23, 2016
Lodovico Giaretta
Aug 23, 2016
Lodovico Giaretta
Jan 10
Bolpat
August 21, 2016
https://issues.dlang.org/show_bug.cgi?id=16410

--- Comment #1 from Lodovico Giaretta <lodovico@giaretart.net> ---
I forgot to mention that if Bar is a templated struct, attribute inference
happens correctly, even with an explicit return type.
So this is a bug specific to templated classes.

--
August 21, 2016
https://issues.dlang.org/show_bug.cgi?id=16410

b2.temp@gmx.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|rejects-valid               |
                 CC|                            |b2.temp@gmx.com
           Severity|major                       |enhancement

--- Comment #2 from b2.temp@gmx.com ---
This is an enhancement request not a bug report.

The member function itself is not a template and since attribs are infered only for templated functions the error message is correct.

With "auto" return type the member function becomes a template so it works. It would also work with a template this parameter or with empty CT parameters.

°°°°°°°°°°°°°°°°°°°°°°°
class Bar(T)
{
    T t;
    ulong a()(){return t.length;}
    ulong b(this T)(){return t.length;}
    auto c(){return t.length;}
}

@nogc void main()
{
    import std.experimental.allocator;
    import std.experimental.allocator.mallocator;
    auto alloc = Mallocator.instance;
    auto a = alloc.make!(Bar!string).a;
    auto b = alloc.make!(Bar!string).b;
    auto c = alloc.make!(Bar!string).c;
}
°°°°°°°°°°°°°°°°°°°°°°°

Definitively not a "rejects-valid".

--
August 21, 2016
https://issues.dlang.org/show_bug.cgi?id=16410

--- Comment #3 from Lodovico Giaretta <lodovico@giaretart.net> ---
(In reply to b2.temp from comment #2)
> This is an enhancement request not a bug report.

I have to disagree with you. See my points below.

> The member function itself is not a template and since attribs are infered only for templated functions the error message is correct.

The member function is not a template, but it's part of a template and depends on the template arguments. I would understand your point if the function did not depend on T.

Also, the same thing, with `struct Bar(T)` instead of `class Bar(T)` supports inference, so your argument does not hold, because even there the member function is not a template itself, but only part of a template.

> With "auto" return type the member function becomes a template so it works.

I don't think that `auto` as a return types makes a function become a template. If it does, it's worth an enhancement, as I don't want the following function to be a template, it does not make any sense:

auto get3() { return 3UL; }

--
August 21, 2016
https://issues.dlang.org/show_bug.cgi?id=16410

--- Comment #4 from b2.temp@gmx.com ---
(In reply to Lodovico Giaretta from comment #3)
> (In reply to b2.temp from comment #2)
> > With "auto" return type the member function becomes a template so it works.
> 
> I don't think that `auto` as a return types makes a function become a template. If it does, it's worth an enhancement, as I don't want the following function to be a template, it does not make any sense:
> 
> auto get3() { return 3UL; }

Yes you're right this is not a template:

https://dlang.org/spec/attribute.html#auto

but auto return type is made for this case, i.e when attribute inference is needed.

--
August 21, 2016
https://issues.dlang.org/show_bug.cgi?id=16410

--- Comment #5 from Lodovico Giaretta <lodovico@giaretart.net> ---
(In reply to b2.temp from comment #4)
> but auto return type is made for this case, i.e when attribute inference is needed.

The problem is that I'm in this situation:

==========================
interface Foo
{
    int doSomething();
}
class Bar(T): Foo
{
    override int doSomething()
    {
        // do something with T
    }
}
==========================

There's no way to have Bar.doSomething @nogc currently because
1) I cannot put @nogc on Foo.doSomething, because in general it is not @nogc.
2) I cannot put @nogc on Bar.doSomething, because it may use the gc depending
on T
3) I cannot use the "auto return trick" to trigger inference, because auto
return cannot be used with override.

So currently there's no way to use Bar!T in @nogc code even for T's that are @nogc.

--
August 21, 2016
https://issues.dlang.org/show_bug.cgi?id=16410

b2.temp@gmx.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|b2.temp@gmx.com             |
           Severity|enhancement                 |major

--- Comment #6 from b2.temp@gmx.com ---
(In reply to Lodovico Giaretta from comment #1)
> I forgot to mention that if Bar is a templated struct, attribute inference
> happens correctly, even with an explicit return type.
> So this is a bug specific to templated classes.

oops I've forget to read that. Repairing modifications now.

--
August 23, 2016
https://issues.dlang.org/show_bug.cgi?id=16410

Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy@yahoo.com

--- Comment #7 from Steven Schveighoffer <schveiguy@yahoo.com> ---
I thought that templated classes would infer attributes. But thinking about this some more, I wonder if that's correct for virtual base functions?

I can envision this scenario:

class Foo(T)
{
   string bar() { return "hi"; }
}

class Bar(T) : Foo!T
{
   override string bar() { return super.bar() ~ T.stringof; }
}

Should Foo(T).bar be @nogc? It would be inferred that if Foo was a struct. But in this case, it is preventing possibly intended behavior.

--
August 23, 2016
https://issues.dlang.org/show_bug.cgi?id=16410

--- Comment #8 from Lodovico Giaretta <lodovico@giaretart.net> ---
(In reply to Steven Schveighoffer from comment #7)
> I thought that templated classes would infer attributes. But thinking about this some more, I wonder if that's correct for virtual base functions?
> 
> I can envision this scenario:
> 
> class Foo(T)
> {
>    string bar() { return "hi"; }
> }
> 
> class Bar(T) : Foo!T
> {
>    override string bar() { return super.bar() ~ T.stringof; }
> }
> 
> Should Foo(T).bar be @nogc? It would be inferred that if Foo was a struct. But in this case, it is preventing possibly intended behavior.

Sorry, I don't understand why Foo!T.bar being @nogc would prevent possibly intended behaviour. Can you please elaborate on this?

--
August 23, 2016
https://issues.dlang.org/show_bug.cgi?id=16410

Lodovico Giaretta <lodovico@giaretart.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|attribute inference inside  |attribute inference for
                   |templated classes           |final methods of templated
                   |                            |classes
           Severity|major                       |normal

--- Comment #9 from Lodovico Giaretta <lodovico@giaretart.net> ---
(In reply to Lodovico Giaretta from comment #8)
> Sorry, I don't understand why Foo!T.bar being @nogc would prevent possibly intended behaviour. Can you please elaborate on this?

Nevermind, got that. If a method is inferred @nogc, it can no longer be overridden as non-@nogc. This is correct. My bad.

Then a new question arises: why cannot attribute inference happen for *final* methods of templated classes?

--
August 23, 2016
https://issues.dlang.org/show_bug.cgi?id=16410

--- Comment #10 from Lodovico Giaretta <lodovico@giaretart.net> ---
(In reply to Lodovico Giaretta from comment #9)
> Then a new question arises: why cannot attribute inference happen for *final* methods of templated classes?

Small precisation: I mean *final override* methods. For final (non-virtual) methods it already happens.

--
« First   ‹ Prev
1 2