https://d.puremagic.com/issues/show_bug.cgi?id=12287
Vladimir Panteleev changed:
What|Removed |Added
CC||thecybersha...@gmail.com
--- Co
https://d.puremagic.com/issues/show_bug.cgi?id=12287
--- Comment #2 from Vladimir Panteleev 2014-03-02
23:42:03 EET ---
I think this only applies to eponymous templates. The parent of the member is
the struct declaration, the parent of which is the template instance. But when
referring to the
https://d.puremagic.com/issues/show_bug.cgi?id=12287
Vladimir Panteleev changed:
What|Removed |Added
Keywords||pull
--- Comment #3 from Vladim
https://d.puremagic.com/issues/show_bug.cgi?id=12287
--- Comment #4 from Kenji Hara 2014-03-02 18:19:10 PST ---
(In reply to comment #2)
> I think this only applies to eponymous templates. The parent of the member is
> the struct declaration, the parent of which is the template instance. But wh
https://d.puremagic.com/issues/show_bug.cgi?id=12287
--- Comment #5 from Vladimir Panteleev 2014-03-03
04:21:23 EET ---
(In reply to comment #4)
> No, this is a Phobos bug. I think it's not good to add a special case in
> __traits(parent) for eponymous templates.
How can you fix it in Phobos,
https://d.puremagic.com/issues/show_bug.cgi?id=12287
--- Comment #6 from Kenji Hara 2014-03-02 18:33:03 PST ---
(In reply to comment #5)
> (In reply to comment #4)
> > No, this is a Phobos bug. I think it's not good to add a special case in
> > __traits(parent) for eponymous templates.
>
> How
https://d.puremagic.com/issues/show_bug.cgi?id=12287
--- Comment #7 from Vladimir Panteleev 2014-03-03
04:34:43 EET ---
OK, so you pattern-match the template.
But I don't think this is a good solution, because any recursive use of
__traits(parent) will need to take care of this special case.
https://d.puremagic.com/issues/show_bug.cgi?id=12287
--- Comment #9 from Vladimir Panteleev 2014-03-03
04:49:01 EET ---
(In reply to comment #8)
> Because your compiler change will make some part of the internal structure of
> the template instantiation invisible.
I don't understand. Why?
B
https://d.puremagic.com/issues/show_bug.cgi?id=12287
--- Comment #8 from Kenji Hara 2014-03-02 18:46:53 PST ---
(In reply to comment #7)
> OK, so you pattern-match the template.
>
> But I don't think this is a good solution, because any recursive use of
> __traits(parent) will need to take car
https://d.puremagic.com/issues/show_bug.cgi?id=12287
--- Comment #11 from Vladimir Panteleev 2014-03-03
05:03:05 EET ---
(In reply to comment #10)
> But, latter semantic analysis will translate X!foo to X!foo.X again. The
> behavior is not directly related to the __traits(parent) behavior.
Th
https://d.puremagic.com/issues/show_bug.cgi?id=12287
--- Comment #10 from Kenji Hara 2014-03-02 19:00:17 PST
---
(In reply to comment #9)
> (In reply to comment #8)
> > Because your compiler change will make some part of the internal structure
> > of
> > the template instantiation invisible.
https://d.puremagic.com/issues/show_bug.cgi?id=12287
--- Comment #12 from Vladimir Panteleev 2014-03-03
05:14:12 EET ---
(In reply to comment #10)
> template S(T)
> {
> struct S {}
>
> int x;
> static assert(__traits(isSame, __traits(parent, S),
>
https://d.puremagic.com/issues/show_bug.cgi?id=12287
--- Comment #13 from Kenji Hara 2014-03-02 19:41:13 PST
---
(In reply to comment #11)
> The __traits code runs semantic on its result immediately after calculating
> the
> parent. So "later" here means "immediately after".
The semantic wil
https://d.puremagic.com/issues/show_bug.cgi?id=12287
--- Comment #14 from Vladimir Panteleev 2014-03-03
05:53:28 EET ---
(In reply to comment #13)
> The semantic will return ScopeExp, and it still contain the TemplateInstance
> object. So you are misunderstanding.
I just checked again with a
https://d.puremagic.com/issues/show_bug.cgi?id=12287
--- Comment #15 from Kenji Hara 2014-03-02 20:35:34 PST
---
(In reply to comment #14)
> (In reply to comment #13)
> > The semantic will return ScopeExp, and it still contain the TemplateInstance
> > object. So you are misunderstanding.
>
>
https://d.puremagic.com/issues/show_bug.cgi?id=12287
--- Comment #16 from Vladimir Panteleev 2014-03-03
06:50:26 EET ---
I use __traits(parent) in my code as well. Just because you added the crutch to
one of the uses of __traits(parent) in the standard library doesn't mean that
the problem is
https://d.puremagic.com/issues/show_bug.cgi?id=12287
--- Comment #17 from Vladimir Panteleev 2014-03-03
07:00:55 EET ---
If we are to go with a library solution, then parentOf needs to be made public,
documented, and advocated in favor of the __traits primitive. And the
documentation of the __
/a4aa5d8a15ed48f17ec4e70151faddcd886f7b89
fix Issue 12287 - infinite loop on std.traits.moduleName on templated struct
member
https://github.com/D-Programming-Language/phobos/commit/b0aabc6c9328ee2a83a0cdb3863d55ba7ee71342
Merge pull request #1978 from 9rnsr/fix12287
Issue 12287 - infinite loop on std.traits.moduleName on
https://d.puremagic.com/issues/show_bug.cgi?id=12287
Andrei Alexandrescu changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://issues.dlang.org/show_bug.cgi?id=12287
Andrej Mitrovic changed:
What|Removed |Added
CC||solta...@gmail.com
--- Comment #19 from An
https://issues.dlang.org/show_bug.cgi?id=12287
Kenji Hara changed:
What|Removed |Added
CC||timothee.co...@gmail.com
--- Comment #20 from K
21 matches
Mail list logo
