On Thursday, October 4, 2018 5:44:55 AM MDT drug via Digitalmars-d-learn wrote: > I was incorrect with description of the problem. The problem is that > there is no simple way to distinct types and symbols if symbols are > private. Because private symbol is not accessible you can not get any > info on it, including is it type or symbol or value. And you can not get > protection for types and values, because they have no protection at all. > So you can not get protection for types and values and can not check if > alias is type, value and symbol because it is private/protected. Vicious > circle. > > Specific case https://run.dlang.io/is/CAoxXO > > Honestly, if `isType` can recognize private members the problem would be > solved. But I think `isSymbol` and `isValue` (working with private > members) will make situation more consistent. > > > Current workaround with fields is using FieldNameTuple. But I fails to > work around private enums.
It's a known issue that you can't properly do type introspection on private symbols from other modules, and it needs to be fixed in the language. It shouldn't be possible to actually use private symbols from other modules, but it should be possible to get type information on them. In his dconf talk this year, Andrei discussed adding wrappers around all of the various traits that present the type information as a set of structs so that you can easily and consistently get at it all instead of having to piece it all together like you do now. He has a partial prototype, though I don't know if he's made it public aside from what he showed in his sides, and it's just wrapping the current stuff, so it's not addding any information, just better organizing it. However, to get where he wants to go with it, problems like this with private symbols are pretty much going to have to be solved. Either way, the access level issues are a language issue and not something that can be fixed by std.traits. - Jonathan M Davis
