www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - __traits(parent) bug?

reply Jack Applegame <japplegame gmail.com> writes:
 struct Foo {
    struct Bar(T) {
        T x;
    }
 }


I expect the value of `__traits(parent, Foo.Bar!int)` is `Foo`, 
but it is `Foo.Bar!int`.

Yes, it looks like the type is the parent of itself. :-)

I know that `Foo.Bar!int` is internally `Foo.Bar!int.Bar`, but I 
believe this behavior of `__traits(parent)` is wrong.

Also consider, please, another question - 
https://forum.dlang.org/thread/oyysbwgkycbmwuoifkky forum.dlang.org
Oct 23 2020
parent reply Paul Backus <snarwin gmail.com> writes:
On Friday, 23 October 2020 at 14:12:59 UTC, Jack Applegame wrote:

 struct Foo {
    struct Bar(T) {
        T x;
    }
 }


 I expect the value of `__traits(parent, Foo.Bar!int)` is `Foo`, 
 but it is `Foo.Bar!int`.

 Yes, it looks like the type is the parent of itself. :-)

 I know that `Foo.Bar!int` is internally `Foo.Bar!int.Bar`, but 
 I believe this behavior of `__traits(parent)` is wrong.

 Also consider, please, another question - 
 https://forum.dlang.org/thread/oyysbwgkycbmwuoifkky forum.dlang.org


IMO the real issue here is that, even if you apply 
__traits(parent) multiple times, the compiler will never give you 
`Foo`, because it re-evaluates the result of each 
__traits(parent) expression from `Foo.Bar!int` (the template) to 
`Foo.Bar!int.Bar` (the eponymous member).

I'm not sure that this can really be called a bug, per se--the 
language spec is vague enough to allow either interpretation--but 
I'd be very surprised if this behavior was intentional.
Oct 24 2020
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Saturday, 24 October 2020 at 15:45:03 UTC, Paul Backus wrote:


 I'm not sure that this can really be called a bug, per se--the 
 language spec is vague enough to allow either 
 interpretation--but I'd be very surprised if this behavior was 
 intentional.


The rewrite to get the eponymous member is applied to the parent 
:)
Not intentional but a consequence of the rewrite rule.
Oct 24 2020
next sibling parent Paul Backus <snarwin gmail.com> writes:
  On Saturday, 24 October 2020 at 17:46:55 UTC, Stefan Koch wrote:

 On Saturday, 24 October 2020 at 15:45:03 UTC, Paul Backus wrote:


 I'm not sure that this can really be called a bug, per se--the 
 language spec is vague enough to allow either 
 interpretation--but I'd be very surprised if this behavior was 
 intentional.


 The rewrite to get the eponymous member is applied to the 
 parent :)
 Not intentional but a consequence of the rewrite rule.


Here's how the language spec defines the rewrite rule:


 If a template contains members whose name is the same as the 
 template identifier then these members are assumed to be 
 referred to in a template instantiation


This paragraph refers specifically to "a template instantiation", 
which is defined on the same page as either an explicit 
instantiation of the form `Template!Args` [1], or an implicit 
instantiation of a function template [2]. A __traits expression 
is neither of these.

So, it's a consequence of the way the rewrite rule is currently 
implemented, but the spec would also permit an implementation 
that worked differently.

[1] 
https://dlang.org/spec/template.html#explicit_tmp_instantiation
[2] https://dlang.org/spec/template.html#function-templates
Oct 24 2020
prev sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Saturday, 24 October 2020 at 17:46:55 UTC, Stefan Koch wrote:

 On Saturday, 24 October 2020 at 15:45:03 UTC, Paul Backus wrote:


 I'm not sure that this can really be called a bug, per se--the 
 language spec is vague enough to allow either 
 interpretation--but I'd be very surprised if this behavior was 
 intentional.


 The rewrite to get the eponymous member is applied to the 
 parent :)
 Not intentional but a consequence of the rewrite rule.


Where is this behavior documented?
Oct 25 2020