www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Compile time sequences

reply drug <drug2004 bk.ru> writes:
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?
Oct 03 2018
parent reply Paul Backus <snarwin gmail.com> writes:
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.
Oct 03 2018
parent reply drug <drug2004 bk.ru> writes:
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.
Oct 03 2018
parent reply drug <drug2004 bk.ru> writes:
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.
Oct 04 2018
next sibling parent drug <drug2004 bk.ru> writes:
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
Oct 04 2018
prev sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Oct 04 2018