Conversation

JT
@jntrnr
This has some good "nerd snipe" potential for programming language designers. In grad school, I was poking around possible solutions to this (though sadly didn't go far enough). A possible direction - modules could expose all of their implied imports to configurability.
Quote Tweet
Jonathan Müller
@foonathan
·
I wrote my thoughts about writing a new type vs adding new functions to change behavior: saturating_add vs. saturating_int – new function vs. new type? foonathan.net/2022/03/behavi #cpp #cplusplus
2
7
JT
@jntrnr
This would mean even operators. You could bring a module into scope and then configure its + over ints to saturate by replacing the implied import (you could think of this similar to capabilities also). This would trickle through additional modules that module uses, and so on.
1
2
JT
@jntrnr
Basically each module has default imports that it draws from where it's imported. On a related note - something that came up the other day in chatting with another Rust dev: you can't easily replace a dependency one of your dependencies use. This means as your project grows...
1
JT
@jntrnr
...you end up taking three different async runtime variations, four different error handling variations, and so on. You can't easily say "this is the one true way", and collapse your transitive deps together. Wouldn't it be nice if there was a solution to both kinds of issues?
4
2
Lars Bergstrom
@larsberg_
You are giving me flashbacks to the meeting when we were discussing the shape of module systems for Rust! I was hot off the heels of grad school with Dave MacQueen, deeply steeped in the SML module system. The term did not yet exist, but I nearly got yeet'd into the pacific.
2
2
Brendan Zabarauskas
@brendanzab
Wow interesting, when was that? IIRC there were early ideas for adding SML-style modules to Rust, but they ended up going with type class style overloading with traits?
1