I was looking in List for a way to join a list of strings together but was surprised it was in Str. I assumed functions in the standard lib were namespaced with the type they accept as the first argument (which is pretty intuitive to me).
If I understand the reason why it's in Str it will help me know where to look in the future.
I had the same reaction.
Also in my 2d array library I have a function Array2D.joinWith that works the same way, it just take two joining strings to join both elements and rows. It feels a bit awkward that my function doesn't mirror the built-ins. I could do Array2D.Str.joinWith but that didn't seem worth it.
I think it is for reading with intuitive name. List.joinWith would have nothing to do with strings. It would be for any arbitrary list.
I guess it could be List.joinStrings but that doesn't feel better to me.
@Brendan Hansknecht there are a lot of functions in List that only work on Num (such as List.sum). I wouldn't want it to be Num.sum, but you could make the same argument for it.
yeah, fair.
Though I do think joinWith is too generic of a name to just put in List. (if it only works for strings)
the Str module currently depends on List and not the other way around
it's technically possible to cheat our way into circular dependncies in builtin modules (e.g. for Num.toStr, since Str certainly depends on Num) but I like to minimize that
I don't think it's too bad the way it is. Where would you want the function to live ideally?
@Richard Feldman good to know, I didn't realize it was an internal dependency reason. I suppose it's a balance between an ideal interface and a clean implementation (if List.joinWith would be ideal).
I would expect List.joinWith to do the same as List.join but with the specified separator interspersed
yeah same :big_smile:
Last updated: Dec 21 2025 at 12:15 UTC