-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add String.{Set,Map} ? #2302
Add String.{Set,Map} ? #2302
Conversation
Hmm. I thought the example you gave worked now, actually. I would like to see |
That seems like an anti-pattern: you're adding dependencies between modules in the stdlib, which we probably want to avoid in general, forcing (IIUC) more things to get linked whenever someone uses We had been using this pattern extensively in core for a long time, and have now been moving away from it in our new libraries (e.g. |
I'm not sure on the scale of the stdlib that there is any real problem with dependencies here. The alternative is presumably to adopt the Base-style approach within |
Well, I suspect that with that way of thinking it might actually become a problem at some point, at which point you've already lost.
... to do nothing?
That's a pretty big if. |
If there are people willing to work on this, doing nothing isn't really a good option. There is clear value in having the standard library provide basic data structures over basic types, without having to clutter up user code instantiating them, and with consistent easily-discoverable naming provided. These structures should fit within a framework such that in a typical program the majority---if not all---types can be equipped with them and satisfy standard interfaces. (The same goes for printing functions.) It really is very convenient when you can just say As far as the implementation goes, @sliquister is probably the expert on this, but from what I remember we didn't really have any problem with the submodule approach until our tree scaled up to be at a very large scale. I don't think it should be dismissed outright. |
If we're concerned about creating inter-dependencies, perhaps another module e.g. |
( |
I don't like this idea. I often find that beyond two module levels code readability suffers. Both because of the resulting length of identifiers which hinders writing compact code (by which I mean sequences of And of course you could not open such a module as it would override Somehow the |
If we want to avoid linking too much, how about defining a module
and then in
Then, if I understand module aliases correctly, linking with |
@dbuenzli Wouldn't this hypothetical |
There isn't clear agreement on this PR, so closing. |
Opinions? One downside is that it breaks the idiom
which may be quite widespread.