3 ms·

There's still some interest in fixing it in a future edition, if we can find the right design that won't create a substantial amount of churn or pitfalls. The

There's still some interest in fixing it in a future edition, if we can find the right design that won't create a substantial amount of churn or pitfalls. The 2018 module system was already a substantial redesign, and because of that, we chose to carefully minimize churn to existing programs (which involved two iterations on the design before the 2018 edition released); the vast majority of programs designed for Rust 2015 will Just Work with the 2018 module system. A future edition could very carefully allow for filesystem-based modules, and focus primarily on that without having to deal with other module system changes at the same time. I can imagine some possibilities that might achieve that, if someone has the bandwidth and diligence to work on it and test it.

MrBuddyCasino 6y ago
> which involved two iterations on the design before the 2018 edition released Just to be clear, I have the highest respect fo the Rust core team, I've followed some discussions and you guys are going above and beyond carefully weighing all the pros and cons, often to an exhaustive degree. I feel the main strength of Rust is also its biggest weakness: alway striving for the perfect, platonic ideal solution, and going the extra mile to get there, which then might discard a much simpler but slightly less powerful solution. Often thats a good thing, not sure it was warranted for the module system. I remember there were different opinions in the core team, Aaron being a proponent of the simple version I think.