www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - how to determine of a module or any other symbol is visible?

reply Mr.Bingo <Bingo Namo.com> writes:
In the code I posted before about CRC, sometimes I get a 
visibility error for some modules. I would like to be able to 
filter those out using traits. Is there any way to determine if a 
module is visible/reachable in the current scope?

The modules that are causing the problems are imported from other 
code that imports them privately. The iteration code still finds 
the module and tries to access it but this then gives a 
visibility error/warning.
Jun 18 2018
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 18/06/2018 9:03 PM, Mr.Bingo wrote:

 In the code I posted before about CRC, sometimes I get a visibility 
 error for some modules. I would like to be able to filter those out 
 using traits. Is there any way to determine if a module is 
 visible/reachable in the current scope?
 
 The modules that are causing the problems are imported from other code 
 that imports them privately. The iteration code still finds the module 
 and tries to access it but this then gives a visibility error/warning.


Quite often when working with CTFE&traits, the easiest thing to do, is 
to do a check to see if whatever you're doing compiles. Nice and simple!
Jun 18 2018
parent reply Mr.Bingo <Bingo Namo.com> writes:
On Monday, 18 June 2018 at 09:10:59 UTC, rikki cattermole wrote:

 On 18/06/2018 9:03 PM, Mr.Bingo wrote:

 In the code I posted before about CRC, sometimes I get a 
 visibility error for some modules. I would like to be able to 
 filter those out using traits. Is there any way to determine 
 if a module is visible/reachable in the current scope?
 
 The modules that are causing the problems are imported from 
 other code that imports them privately. The iteration code 
 still finds the module and tries to access it but this then 
 gives a visibility error/warning.


 Quite often when working with CTFE&traits, the easiest thing to 
 do, is to do a check to see if whatever you're doing compiles. 
 Nice and simple!


This doesn't work with depreciation warnings.
Jun 18 2018
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 18/06/2018 9:24 PM, Mr.Bingo wrote:

 On Monday, 18 June 2018 at 09:10:59 UTC, rikki cattermole wrote:

 On 18/06/2018 9:03 PM, Mr.Bingo wrote:

 In the code I posted before about CRC, sometimes I get a visibility 
 error for some modules. I would like to be able to filter those out 
 using traits. Is there any way to determine if a module is 
 visible/reachable in the current scope?

 The modules that are causing the problems are imported from other 
 code that imports them privately. The iteration code still finds the 
 module and tries to access it but this then gives a visibility 
 error/warning.


 Quite often when working with CTFE&traits, the easiest thing to do, is 
 to do a check to see if whatever you're doing compiles. Nice and simple!


 
 This doesn't work with depreciation warnings.


There won't be a way to check for those (I think).
Easier to not worry about them until it turns into errors.
Jun 18 2018
next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, June 18, 2018 21:28:00 rikki cattermole via Digitalmars-d-learn 
wrote:

 On 18/06/2018 9:24 PM, Mr.Bingo wrote:

 On Monday, 18 June 2018 at 09:10:59 UTC, rikki cattermole wrote:

 On 18/06/2018 9:03 PM, Mr.Bingo wrote:

 In the code I posted before about CRC, sometimes I get a visibility
 error for some modules. I would like to be able to filter those out
 using traits. Is there any way to determine if a module is
 visible/reachable in the current scope?

 The modules that are causing the problems are imported from other
 code that imports them privately. The iteration code still finds the
 module and tries to access it but this then gives a visibility
 error/warning.


 Quite often when working with CTFE&traits, the easiest thing to do, is
 to do a check to see if whatever you're doing compiles. Nice and
 simple!


 This doesn't work with depreciation warnings.


 There won't be a way to check for those (I think).
 Easier to not worry about them until it turns into errors.


IIRC, there __traits(isDeprecated, symbol) should work now, though it's a
recent addition.

- Jonathan M Davis
Jun 18 2018
prev sibling parent reply Cauterite <cauterite gmail.com> writes:
On Monday, 18 June 2018 at 09:28:00 UTC, rikki cattermole wrote:

 On 18/06/2018 9:24 PM, Mr.Bingo wrote:

 On Monday, 18 June 2018 at 09:10:59 UTC, rikki cattermole 
 wrote:
 This doesn't work with depreciation warnings.


 There won't be a way to check for those (I think).
 Easier to not worry about them until it turns into errors.


you can try the -de flag:

// foo.d:
deprecated void foo() {}
pragma(msg, __traits(compiles, foo()));

---

dmd foo.d
-> true

dmd -de foo.d
-> false

---

couldn't think of any examples of deprecated visibility to try 
though
Jun 18 2018
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, June 18, 2018 11:53:50 Cauterite via Digitalmars-d-learn wrote:

 On Monday, 18 June 2018 at 09:28:00 UTC, rikki cattermole wrote:

 On 18/06/2018 9:24 PM, Mr.Bingo wrote:

 On Monday, 18 June 2018 at 09:10:59 UTC, rikki cattermole
 wrote:
 This doesn't work with depreciation warnings.


 There won't be a way to check for those (I think).
 Easier to not worry about them until it turns into errors.


 you can try the -de flag:

 // foo.d:
 deprecated void foo() {}
 pragma(msg, __traits(compiles, foo()));

 ---

 dmd foo.d
 -> true

 dmd -de foo.d
 -> false

 ---

 couldn't think of any examples of deprecated visibility to try
 though


Turning things into errors affects type introspection - e.g. the result on
__traits(comiles, ...) - so it's usually a bad idea. It's bad enough that -w
is a compiler flag without adding -de into the mix. That just makes it easy
to end up with code that doesn't compile or takes an unintended branch of a
static if, because a symbol was recently deprecated, and the code hasn't
been updated yet.

- Jonathan M Davis
Jun 18 2018