According to https://dlang.org/articles/ctarguments.html compile time sequences "...allow a programmer to operate on types, symbols and values..."
Phobos has `isType`/`isTypeTuple` traits, also `isExpressions` where expression may contain both values and symbols, but has no traits like `isSymbol` and `isValue`. I handle this by taking an address - values has no address, so I can distinct types, symbols and values, but it's not convenient/consistent way. I think it worths to add such traits, but probably I missed something?

On Wednesday, 3 October 2018 at 07:57:07 UTC, drug wrote:
> According to https://dlang.org/articles/ctarguments.html compile time sequences "...allow a programmer to operate on types, symbols and values..."
> Phobos has `isType`/`isTypeTuple` traits, also `isExpressions` where expression may contain both values and symbols, but has no traits like `isSymbol` and `isValue`. I handle this by taking an address - values has no address, so I can distinct types, symbols and values, but it's not convenient/consistent way. I think it worths to add such traits, but probably I missed something?

In my experience doing metaprogramming in D, it's best to make your static if/template constraint tests as narrow and specific as possible. For example, if you want to know whether you can call a function with a particular argument, you don't need to muck around with std.traits; you can just check whether the function call compiles:

    static if(__traits(compiles, f(arg))) {
        // do something with f(arg)
    }

So my question to you is: why do you care whether something is a symbol or a value? Is there actually a more specific question that you're trying to answer with that information? If so, just ask the more specific question directly.

On 03.10.2018 20:22, Paul Backus wrote:
> 
> In my experience doing metaprogramming in D, it's best to make your static if/template constraint tests as narrow and specific as possible. For example, if you want to know whether you can call a function with a particular argument, you don't need to muck around with std.traits; you can just check whether the function call compiles:
> 
>      static if(__traits(compiles, f(arg))) {
>          // do something with f(arg)
>      }
> 
> So my question to you is: why do you care whether something is a symbol or a value? Is there actually a more specific question that you're trying to answer with that information? If so, just ask the more specific question directly.
I did like you does. It failed. It's suitable for some local things, but if you need more general solution it fails. You don't know why your code doesn't compile. If `f` is template it can hurt because failed instantiation may lead to wrong code path you don't expect. For example your code has two paths - when the code compiles and doesn't. You or someone else later adds template function like `f` but makes just typo in function body - wrong code path taken and you won't know it until start fixing bug somewhere else.
Now I prefer to use `hasMember` and also check args at least for length.
More specific question is that I distinct values and symbols by taking address and it looks like hack for me. I'll try to show example later.

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.

04.10.2018 14:44, drug пишет:
> 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.
> 

I forget about scope in static foreach, this correct version:https://run.dlang.io/gist/97294d89d5c0b89ebcf009c18c4743d4

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