Re: FieldNameTuple!T and std.traits.Fields!T not empty for interfaces

2019-06-08 Thread Steven Schveighoffer via Digitalmars-d-learn

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


Re: FieldNameTuple!T and std.traits.Fields!T not empty for interfaces

2019-06-07 Thread Amex via Digitalmars-d-learn
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.





Re: FieldNameTuple!T and std.traits.Fields!T not empty for interfaces

2019-06-06 Thread Jonathan M Davis via Digitalmars-d-learn
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





Re: FieldNameTuple!T and std.traits.Fields!T not empty for interfaces

2019-06-06 Thread Steven Schveighoffer via Digitalmars-d-learn

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


Re: FieldNameTuple!T and std.traits.Fields!T not empty for interfaces

2019-06-06 Thread Steven Schveighoffer via Digitalmars-d-learn

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



Re: FieldNameTuple!T and std.traits.Fields!T not empty for interfaces

2019-06-06 Thread Steven Schveighoffer via Digitalmars-d-learn

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


Re: FieldNameTuple!T and std.traits.Fields!T not empty for interfaces

2019-06-06 Thread Adam D. Ruppe via Digitalmars-d-learn

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.


FieldNameTuple!T and std.traits.Fields!T not empty for interfaces

2019-06-06 Thread Amex via Digitalmars-d-learn

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?