This is a must, the more modules your project contains, the harder is to avoid cyclic import, to the point of making the compiler happy in spite of readability and organization. This is an issue/pain in the ass for big projects.
But also, from what Araq has said on irc, it should be implemented eventually, but i dont think it will make it to 1.0
Any project that is not a toy one will eventually run into this issue. I don't have any choice but I don't like splitting types and procs, produces more modules and readability suffers (You can define two types together that are related, but you cannot do the same with certain types and procs).
The biggest issue for me is that to work around cyclic imports sometimes you have to think deeply how to reorganize your code, and end up with a unintuitive module structure. When something is beyond saving I declare a proc var and later assign a proc to it because any other alternative is to fuck up your code even further.
As far as I'm concerned this cannot be fixed because macros and templates complicates the issue.
I 'll try to concentrate the simple types only (not compound types), in their own module and try to keep a very hierarchical project structure, I hope it will be enough !
In fact, we have a figured out quite a few details already of how a pre-pass in the compiler could work to provide this feature.
If the compiler can smartly import required modules, with the "--path" command only, the need to explicitly import modules may be removed in most cases right ?
Thanks everyone for your ideas. I guess the lack of reply on the actual RFC means it's not happening, or maybe it ran into some kind of roadblock?
@dom96 That seems like the most appropriate solution right now, but then you lose the ability to do access control and have private vars, because the procs are in separate files, right?
@Arrrrrrrrr: Yes, exactly! Most large projects eventually runs into some form of cyclic dependencies, and having to work around it can end up making the code substantially more complicated. It's true that this RFC wouldn't work with macro and template type declarations, but I wouldn't mind just avoiding them when declaring cyclic types. It's usually only a few "problem" types per project anyways.
One recipe I tend to use:
Place imports (some not all) after type definitions in this way you don't need separate type modules and you actually avoid circular dependencies.
I guess the lack of reply on the actual RFC means it's not happening, or maybe it ran into some kind of roadblock?
Any proposal which cannot deal with macros is hard to accept. There seems to be an overlap between the people who like cyclic imports and those who use OO designs with class-like macros.