https://issues.dlang.org/show_bug.cgi?id=24516
--- Comment #2 from Jonathan M Davis <issues.dl...@jmdavisprog.com> --- (In reply to Nick Treleaven from comment #1) > > S.tupleof > > I don't think it makes sense to allow `tupleof` to be a type property. It > should be instance only. The spec does not mention its use on a type. > https://dlang.org/spec/class.html#tupleof The spec uses tupleof on a type right there in the example that you're linking to even before it uses it on a variable: --- class Foo { int x; long y; } static assert(__traits(identifier, Foo.tupleof[0]) == "x"); static assert(is(typeof(Foo.tupleof)[1] == long)); --- And both druntime and Phobos having been using tupleof on types for years - e.g. std.traits.Fields. It would break a lot of existing code if tupleof stopped working on types. Also, in most cases, it's less error-prone to do type introspection on types rather than values or symbols. Some kinds of type introspection have to be done on values or symbols, but pretty much any time that a trait takes an alias rather than a type, it makes it far trickier to write it correctly, and corner cases are frequently a problem. If anything, the fact that type qualifers are being lost when aliasing the result of tupleof is an example of why aliasing symbols when doing type introspection (as opposed to aliasing types) tends to be error-prone. We unfortunately have variety of bugs where weird stuff happens like type qualifiers disappearing when operating on symbols rather than on types, and it's why some of the traits in std.traits are overloaded so that they can explicitly take types or use an alias parameter. Using tupleof on an instance has some uses, since then you can do stuff like --- foo.tupleof[0] = 1; --- but when doing type introspection, it makes far more sense to be operating on the type, and tupleof has worked that way for many years. The problem in this bug report is that for some reason, aliasing the result of tupleof results in symbols that behave differently from the direct result of tupleof, and the qualifiers are lost. I see no reason why it should be reasonable for that to happen. --
