From reviewing #31844, it appears that there has been little progress on trait specialization, even though implementing this feature could unlock numerous use cases in scientific computing. With trait specialization, it would be possible to build something conceptually similar to static multiple dispatch, which - as demonstrated by the Julia language - enables significant reusability for scientific computing libraries.
Here is the example of such static multiple dispatch that enables code reuse.
The "always applicable impl" concept discussed in #48538 seems to address the unsoundness issue without imposing a significant penalty on the expressivity of trait specialization. This suggests that there may not be insurmountable technical barriers to implementing the feature.
Is this just a matter of priorities? Does the Rust project not currently aim to appeal to a broader scientific computing audience? Or are there other considerations at play? Could anyone provide insights into why specialization is not being prioritized? Are there specific technical blockers, or is the delay more about aligning the feature with Rust's overall design philosophy?
I don't know the details, but from what I understand specialization is blocked on lifetimes, because the intersection of those 2 features is unsound, and there are currently no viable ideas to solve that.
Based on my understanding of what was discussed during this meeting and the original post about always applicable implementations, lifetimes are not an issue because the type checker guarantees to the compiler that there will only ever be one specialization, regardless of the lifetime. As far as I understand, this effectively prohibits specialization based on lifetimes altogether, which makes perfect sense (though I believe there might be a valid case for supporting 'static).
However, If this is not the case, and the "always applicable impl" restriction is not a true solution to soundness problem, I would greatly appreciate any pointers or further clarification on the matter.
This is understood. What I am asking is why the core team allocates its limited resources the way it does - specifically, why this feature has not been prioritized. Considering its potential impact is extensive and far-reaching, I am curious about the reasoning behind this decision.
My understanding is that basically all improvements to trait impl selection (of which specialization is one) is blocked on the new generation trait solver (chalk). Any developer capable of working on the old/existing trait solver is much more motivated to work on the new one instead, which will also make implementing the needed specialization significantly more straightforward, perhaps even trivial. So work on the next gen trait solver is work on specialization, in a way; completing it is potentially even simpler than making specialization work properly in the existing solver.
I'm not directly involved in that work, though, so this is just hearsay.
We're currently refactoring the way the current "typing mode" is tracked, working to fix trait-system-refactoring#106. An FCP was started to clean up the way we merge candidates when proving trait goals.
With the caveats that priorities aren't determined by voting and this doesn't account for other factors such as complexity, we can still look at the rust survey results from last year and see that for users specialization is not the #1 priority either.
It is great that there is such data. However, I must point out that this survey reflects the opinions of existing language users, not potential users. I would still argue the absence of this feature makes the language less appealing to the scientific computing community.
Regardless, 2023 Annual Rust Survey Results | Rust Blog also has the "Why don't you use Rust?" question, and even within the minority of non-users, "Missing language features" ranked a very low 5%. Of course that's 5% out of all non-user respondents, not just the ones in scientific computing.
Still, given all the data we do have, it seems correct that there's a focus on moving to the new trait solver, and unblocking the very wide range of important issues that's supposed to solve or enable solving.
Thank you for your response. I now understand that the new trait solver is closely tied to many planned features. It would have been helpful if this connection had been mentioned in the related issues, as otherwise, it might give the impression that no progress is being made on implementing those features.
