-
-
Notifications
You must be signed in to change notification settings - Fork 714
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
combine std.array.split() overloads into one #5063
Conversation
8deb8d6
to
c92c5bc
Compare
Rant:
There is no documentation for this, and no unit tests. There are some calls for it in std.algorithm.iterator. Overloads like this are a bad practice. It should have had a different name. |
Well well, turns out there's another overload of split() in std.regex:
No wonder nobody can figure out what is going on in Phobos. |
c92c5bc
to
5b06abe
Compare
So I gave up because the constraints could not be simplified, and settled for putting in a reference to the std.regex.split. |
I've noticed this on other PRs - we seem to have a heisenbug:
|
Introduced by #5042 (comment) There seems to be no interest in tracking & fixing "random" failure type bugs, so have fun. |
@WalterBright This is completely flawed. The whole point of split in std.regex being an overload is so that overload resolution will pick up the right function based on the argument. This allows split to be extensible. Putting all rabble in one place locks down extensibility of split, so please reconsider. |
@DmitryOlshansky I understand the concept, I designed the module system to work that way. Unfortunately, the flip side of this is making code hard to understand. There are too many overloads of split scattered around, and it is hard to see who is calling what. It is too late to change split, as that would break existing code in clumsy ways due to the overloading. I'd like to be able to grep a name and reliably find it. Too much of Phobos has too many overloads, making it unduly difficult to figure out what is happening. With the split in std.regex, it took me a while to figure out that extra overload that I didn't know about in another module was the cause of various problems I was having. Overloading is a great feature, but it is something that should be used with a lot of restraint. Cross-module overloading should have even more restraint. |
Completely disagree. I can trivially show it on the example of Complex type. An std defines Any attempts to merge overloads together just misses this critical point of independent implementations per types involved. |
This replaces 2 overloads of split() with complex constraints into one function, with the variants selected via
static if
. A custom error message is generated for incorrect arguments.One behavior change of this is if someone has their
split(a,b)
function in another import, the compiler will complain about ambiguity for which one to call, as this new version will accept anything fora
andb
. The previous constraints are suspect anyway, as they would accept nonsense likesplit("ab",1)
. I did not correct that issue in this PR.