On Mon, Jun 10, 2013 at 10:20 AM, Steven Schveighoffer <schvei...@yahoo.com>wrote:
> On Sun, 09 Jun 2013 23:15:42 -0400, Timothee Cour < > thelastmamm...@gmail.com> wrote: > > On Fri, Jun 7, 2013 at 11:41 PM, Jonathan M Davis <jmdavisp...@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.
