4 ms·

> Interaction with partial, in-progress programs. People wanted to be able to comment out `mod` declarations to temporarily exclude files from the build. Exce

> Interaction with partial, in-progress programs. People wanted to be able to comment out `mod` declarations to temporarily exclude files from the build. Except the current system actually has the opposite effect -- working with partial programs is actually worse from the standpoint of using rust analyzer. Newbies like myself start writing a new source file and expect that completion and other features will work right away. > Interaction with version control, e.g. `git stash`. Similar to the above, people want to exclude untracked files from the build when their corresponding `mod` declarations are stashed. They can just stash the file as well. This strikes me as making the whole system harder for new people to understand just to smooth over edge cases for power users that definitely have the ability to come up with workarounds.

MrBuddyCasino 6y ago
>This strikes me as making the whole system harder for new people to understand just to smooth over edge cases for power users that definitely have the ability to come up with workarounds. This is exactly what it is, and due to inertia it won't ever change. At this point, there is no other choice but to either accept it or find peace in smth else.
- JoshTriplett 6y ago
  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.
Rusky 6y ago
Note that rust-analyzer could choose to load un-`mod`-ed files with no change to the language. At a minimum, this could be an off-by-default configuration. Ideally, it would suppress errors caused by these extra files, and downgrade errors caused by missing `mod` declarations to warnings, with a quick-fix to add the declaration. > They can just stash the file as well. This is an option, but it's not clear-cut whether it's a better one. See my other comment: https://news.ycombinator.com/item?id=23890842 https://news.ycombinator.com/item?id=23890842 > This strikes me as making the whole system harder for new people to understand just to smooth over edge cases for power users that definitely have the ability to come up with workarounds. This certainly was not the goal. The goal of the 2018 module system changes in general was to make the module system easier to learn than it was before; this aspect was simply retained as-is because we couldn't figure out how to make it better without making existing aspects worse.

MrBuddyCasino 6y ago

>This strikes me as making the whole system harder for new people to understand just to smooth over edge cases for power users that definitely have the ability to come up with workarounds. This is exactly what it is, and due to inertia it won't ever change. At this point, there is no other choice but to either accept it or find peace in smth else.

JoshTriplett 6y ago
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.

Rusky 6y ago

Note that rust-analyzer could choose to load un-`mod`-ed files with no change to the language. At a minimum, this could be an off-by-default configuration. Ideally, it would suppress errors caused by these extra files, and downgrade errors caused by missing `mod` declarations to warnings, with a quick-fix to add the declaration. > They can just stash the file as well. This is an option, but it's not clear-cut whether it's a better one. See my other comment: https://news.ycombinator.com/item?id=23890842 https://news.ycombinator.com/item?id=23890842 > This strikes me as making the whole system harder for new people to understand just to smooth over edge cases for power users that definitely have the ability to come up with workarounds. This certainly was not the goal. The goal of the 2018 module system changes in general was to make the module system easier to learn than it was before; this aspect was simply retained as-is because we couldn't figure out how to make it better without making existing aspects worse.