Add FieldNames, FieldSymbols, and FieldTypes to phobos.sys.traits.

[jmdavis]

FieldNames is roughly equivalent to std.traits' FieldNameTuple, and FieldTypes is roughly equivalent to std.traits' Fields (which used to be FieldTypeTuple).

The primary difference implementation-wise is that the phobos.sys.traits versions require that the types that they're given be aggregate types. For some reason, the std.traits versions accept any type and then try to give a result that at least sort of make sense when they're given a type which isn't an aggregate type (even though they really can't, because a type which isn't an aggregate type has no fields, making any choice kind of arbitrary).

For types which aren't aggregate types, Fields gives the type back in an AliasSeq, and FieldNameTuple gives AliasSeq!"". Neither makes any sense to me. I assume that it was done so that those traits could be used in generic code and work with any type, but realistically, if you want to do anything sane with them, you need to already have verified that you're dealing with an aggregate type, since it's just going to be error-prone to do stuff like Fields!int and then get AliasSeq!int back as if it had a single field of type int (or FieldNameTuple!int and get an empty string as the name). So, the phobos.sys.traits versions simply require that you give them aggregate types to avoid that entire mess.

FieldNames evaluates to the names of the fields as strings. The "Tuple" in the name of the std.traits version is an artifact from when AliasSeqs were called TypeTuples, so I didn't keep that.

FieldTypes evaluates to the types for the fields. It's FieldTypes rather than Fields for clarity, since it's not at all obvious what Fields is supposed to give you (if I'd had to guess, I would have guessed the symbols, not the types).

FieldSymbols is new. Its usefulness is questionable, since it does almost exactly the same thing that tupleof does. However, I've included it because of the subtle issues that you get with nested structs - namely that tupleof includes a context pointer in its result, which you probably don't want (though that obviously depends on what you're doing), and FieldNames and FieldTypes don't include it (just like their std.traits counterparts don't), so it seemed like it would make it less error-prone to have FieldSymbols for the cases where symbols are needed. The documentation explains (and the examples show) the difference between FieldSymbols and tupleof so that the programmer can decide which makes more sense for their particular use case.

[dlang-bot]

Thanks for your pull request, @jmdavis!

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + phobos#8986"