www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - FieldNameTuple!T and std.traits.Fields!T not empty for interfaces

reply Amex <Amex gmail.com> writes:
FieldNameTuple!T
std.traits.Fields!T

are non-empty when T is an interface!

An interface cannot contain fields and yet these return non-zero 
and screws up my code. While I can filter for interfaces it makes 
me wonder what else may slip through?

Is it a bug or what is going on?
Jun 06 2019
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 6 June 2019 at 20:22:26 UTC, Amex wrote:

 Is it a bug or what is going on?


my suspicion is it is actually the pointer to the vtable getting 
caught up in it but idk, i didn't really look, just guessing.
Jun 06 2019
prev sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 6/6/19 4:22 PM, Amex wrote:

 FieldNameTuple!T
 std.traits.Fields!T
 
 are non-empty when T is an interface!
 
 An interface cannot contain fields and yet these return non-zero and 
 screws up my code. While I can filter for interfaces it makes me wonder 
 what else may slip through?
 
 Is it a bug or what is going on?


Can you provide code to demonstrate? I get no fields when I do this:

interface I
{
}

import std.traits;
pragma(msg, FieldNameTuple!I);

-Steve
Jun 06 2019
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 6/6/19 4:43 PM, Steven Schveighoffer wrote:

 On 6/6/19 4:22 PM, Amex wrote:

 FieldNameTuple!T
 std.traits.Fields!T

 are non-empty when T is an interface!

 An interface cannot contain fields and yet these return non-zero and 
 screws up my code. While I can filter for interfaces it makes me 
 wonder what else may slip through?

 Is it a bug or what is going on?


 
 Can you provide code to demonstrate? I get no fields when I do this:
 
 interface I
 {
 }
 
 import std.traits;
 pragma(msg, FieldNameTuple!I);
 


Oh wait! It's not empty, it has an empty string as a single member! 
That's definitely a bug.

-Steve
Jun 06 2019
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 6/6/19 4:49 PM, Steven Schveighoffer wrote:

 Oh wait! It's not empty, it has an empty string as a single member! 
 That's definitely a bug.
 


OK, not a bug, but not what I would have expected. From docs:

"If T isn't a struct, class, or union, an expression tuple with an empty 
string is returned."

I wonder why that behavior is there, certainly it's intentional.

-Steve
Jun 06 2019
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, June 6, 2019 2:52:42 PM MDT Steven Schveighoffer via 
Digitalmars-d-learn wrote:

 On 6/6/19 4:49 PM, Steven Schveighoffer wrote:

 Oh wait! It's not empty, it has an empty string as a single member!
 That's definitely a bug.


 OK, not a bug, but not what I would have expected. From docs:

 "If T isn't a struct, class, or union, an expression tuple with an empty
 string is returned."

 I wonder why that behavior is there, certainly it's intentional.


I guess that whoever wrote it did that rather than making it an error so
that they wouldn't have to first check whether they were passing a type that
even made sense. It still seems like an odd decision though. Normally, you'd
just require that an appropriate type be passed.

- Jonathan M Davis
Jun 06 2019
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 6/6/19 5:36 PM, Jonathan M Davis wrote:

 On Thursday, June 6, 2019 2:52:42 PM MDT Steven Schveighoffer via
 Digitalmars-d-learn wrote:

 On 6/6/19 4:49 PM, Steven Schveighoffer wrote:

 Oh wait! It's not empty, it has an empty string as a single member!
 That's definitely a bug.


 OK, not a bug, but not what I would have expected. From docs:

 "If T isn't a struct, class, or union, an expression tuple with an empty
 string is returned."

 I wonder why that behavior is there, certainly it's intentional.


 
 I guess that whoever wrote it did that rather than making it an error so
 that they wouldn't have to first check whether they were passing a type that
 even made sense. It still seems like an odd decision though. Normally, you'd
 just require that an appropriate type be passed.
 


In fact, it feels like the opposite. Returning a tuple of an empty 
string almost guarantees you will get an error (__traits(getMember, T, 
"") likely is an error).

I just am not sure why someone did that. A perfectly reasonable 
alternative would be simply to return an empty tuple.

-Steve
Jun 08 2019
prev sibling parent Amex <Amex gmail.com> writes:
On Thursday, 6 June 2019 at 20:52:42 UTC, Steven Schveighoffer 
wrote:

 On 6/6/19 4:49 PM, Steven Schveighoffer wrote:

 Oh wait! It's not empty, it has an empty string as a single 
 member! That's definitely a bug.
 


 OK, not a bug, but not what I would have expected. From docs:

 "If T isn't a struct, class, or union, an expression tuple with 
 an empty string is returned."

 I wonder why that behavior is there, certainly it's intentional.

 -Steve


It is wrong, regardless if it is intentional. Every day people do 
intentional things that are wrong.

The problem is that one returns a non-empty tuple and so loops 
will be executed on the empty string. While one can test for the 
empty string return there is absolutely no reason why one 
shouldn't just return an empty tuple as it plays correctly with 
the use case.
Jun 07 2019