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.

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!

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.

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.

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

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

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