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

Steven Schveighoffer schveiguy at gmail.com
Sat Jun 8 20:40:47 UTC 2019


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


More information about the Digitalmars-d-learn mailing list