> > It seems like mix compiles libraries in topological order (based on > declared dependency relationships) so for modules provided by a dependency > (or by Elixir itself) could it provide this? >
For modules that have been previously defined, we can provide this feature but it would be incomplete. For example, if the whole module does not exist, we wouldn't know if it was a typo or something that was meant to be defined by the current project. I honestly think a partial behaviour such as this would be confusing. It's not clear to me why we have to deprecate circular module dependencies > to support this feature as a post-compilation check. > Sorry, we don't need to deprecate circular dependencies to support post-compilation check. I wanted to say we need to use post-compilation checks if we want to deprecate circular module dependencies. This scheme would allow circular module dependencies as we have now, > assuming the post-compilation step does not run until the entire project > has finished compilation. Circular project dependencies would not be > allowed but from what I understand, they are already not allowed > <https://github.com/elixir-lang/elixir/issues/4420>. > Circular dependencies are allowed at runtime but not at compile time. > Any reason such an approach wouldn't work with the existing compiler? > There are many approaches that would work, they all compromise somehow. In particular, if it is a post-compilation check, I don't think it belongs to the compiler but as a separate step, probably a Mix task. -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4Ji6kzB_E232YdWFXnsGLYfVO%3DWDuODxEpNbYo%2BLPE1mw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
