Eli Dowling (Nov 14 2024 at 16:10): Eli Dowling (Nov 14 2024 at 16:10):I have one aspect of this proposal that isn't entirely clear to me.
If I want to add a method for Str types, can I do that, and if so, how?
Eg I want to be able to do
"Hello".myCustomFun(123)
You can not. Has to be part of the Str module
Brendan Hansknecht (Nov 14 2024 at 16:27):you could use the .passTo(myCustomFun, 123) syntex or whatever equivalent if it is added
Eli Dowling (Nov 14 2024 at 16:46):That's what I thought. Seems maybe module extension might be a good feature along with this. Given non-methods are kind of second class in a way that functions outside a module weren't before this proposal.
Brendan Hansknecht (Nov 14 2024 at 16:49):I think they probably would need a separate proposal. I think this proposal intentionally doesn't allow extension (not 100% sure, but pretty certain).
Eli Dowling (Nov 14 2024 at 16:52):Oh I wasn't suggesting it should, more observing that this change makes the lack of module extensions more obvious/maybe an issue.
Brendan Hansknecht (Nov 14 2024 at 16:53):Ah
Brendan Hansknecht (Nov 14 2024 at 16:53):Yeah, definitely creates first and second class for nominal types
Brendan Hansknecht (Nov 14 2024 at 16:53):I'm personally not worried cause it is the standard in basically all languages
Richard Feldman (Nov 14 2024 at 17:43):my default feeling is that it would be a mistake to introduce support for that
Richard Feldman (Nov 14 2024 at 17:44):I'm open to having my mind changed about that, but when I look at the history of things like ActiveSupport in Rails and "bring your own Prelude" in Haskell, it seems to me like "introduce the ability to have competing concepts of the stdlib across the ecosystem" is a bug and not a feature :big_smile:
Sam Mohr (Nov 14 2024 at 18:30):Would also strongly oppose that, it makes discovery of implementations more difficult, allows for very surprising behavior, etc. Though I agree that it should be a separate discussion
Eli Dowling (Nov 14 2024 at 19:57):Interesting, I'm surprised there is such strong opposition. I have found in most projects over a certain size, in languages like Ocaml which absolutely allow extending modules, I always have one or two extensions.
It's just too useful. Particularly: adding new string operations, adding special methods to Option types, making two existing libraries talk to each other.
I'd consider the last one the most significant issue. If I'm using two libraries which don't naturally work together it's often useful to define functions that support conversion etc. Again, not an issue for small toy projects. But in big projects with many developers, it makes sense to be able to modify functionality once and then have other devs easily benefit. Rather than having to make some similarly named module that has you extensions that is less ergonomic and not discoverable. I see it as a way to avoid having to fork the two libraries basically.
Another compelling use case IMO is adding optional functionality to a library. Currently if your platform doesn't provide primatives you need you may not be able to even use some libraries, but if as a library auther you provide a base API+ extensions that require platform stuff like http your library can be more widely used.
Regarding stdlibs:
I don't think the alt StdLib is a real issue. From what I've seen elsewhere I'd expect an alt StdLib too just make a whole new set of modules if I wanted to makes a new stdlib: eg:EliStr and EliDict.
But more importantly I'm not familiar with alternative stdlibs even existing in any language where the existing StdLib wasn't frankly pretty crap. Ocaml has alternatives because the existing one isn't good at actually using Ocaml lnagsuge features. Go doesn't have any I'm aware of, because the existing StdLib feels like idiomatic go.
Brendan Hansknecht (Nov 14 2024 at 20:37):Go kinda has alternatives, but they are always of small chunk of the stdlib. Like fasthttp to replace std/http
Jasper Woudenberg (Nov 14 2024 at 21:57):Eli Dowling said:
But in big projects with many developers, it makes sense to be able to modify functionality once and then have other devs easily benefit. Rather than having to make some similarly named module that has you extensions that is less ergonomic and not discoverable.
Eli, I'm curious about this, can you say more to this point? Are you saying they're more discoverable because they show up in auto-complete menu's on the relevant types?
Sam Mohr (Nov 14 2024 at 22:03):We should have a separate topic to discuss this concept.
Notification Bot (Nov 14 2024 at 22:03):15 messages were moved here from #ideas > static dispatch - proposal by Sam Mohr.
Gábor Librecz (Nov 15 2024 at 11:27):I've built a small command line app in Roc (https://github.com/kuglee/youtube-downloader-roc) and it has 5 Extra modules for various packages. For me it's not about discoverability, I just like how the code reads using them.
I'm coming from Swift where almost every project uses extensions. I think this would be great to have in Roc also.
Last updated: Jun 16 2026 at 16:19 UTC