can we detect at compile time module ctor/dtor cycles ?

[Timothee Cour]

On Mon, Jun 10, 2013 at 10:20 AM, Steven Schveighoffer
<schveiguy at yahoo.com>wrote:

> On Sun, 09 Jun 2013 23:15:42 -0400, Timothee Cour <
> thelastmammoth at gmail.com> wrote:
>
>  On Fri, Jun 7, 2013 at 11:41 PM, Jonathan M Davis <jmdavisProg at gmx.com
>> >wrote:
>>
>>  On Friday, June 07, 2013 23:23:25 Timothee Cour wrote:
>>> > Why can't we detect at compile time module ctor/dtor cycles (instead of
>>> > runtime) ?
>>>
>>> At minimum, separate compilation stops it. A .di file isn't likely to
>>> have
>>> them
>>> even if its corresponding .d file did.
>>>
>>
>>
>> automatically generated di files (eg -Hffilename) *do* generate static
>> this();
>>
>
> .di files do not need to be auto-generated, in fact, in the case where you
> would want to hide implementation, you will manually create them.  And it
> is perfectly legal to omit static ctors in .di files.
>
> But you are missing something important -- it's not just the fact that it
> has static ctors/dtors, there must be an import cycle.  .di files certainly
> may not contain private imports, and you will have no way to construct the
> graph.
>
> -Steve
>


I understand your point, however I argued above that we should run a test
at compile time to detect cycles. It won't catch all cycles (because of
certain di files), but it will catch most of them (at least all of the ones
not involving di files). This would be especially handy for people using
rdmd.
At runtime, we will also run the test to catch all cases.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-learn/attachments/20130617/c9f447bf/attachment.html>