Why are these evolution proposals not moving forward?

Evolution Discussion
1

i’m opening this thread because one of my proposals, Synthesized Comparable for pure enumerations, has been sitting with its swift evolution PR open for nearly a month with no action from core team members who would have the authority to bring it to review. the proposal text is finished, raised issues have been addressed, and its implementation branch has been untouched for about two months now. By all means, the proposal has fulfilled all the requirements to go to community review (except for CI tests, which can only be triggered by members with write-access), yet still, no review has been scheduled.

looking through the list of open pull requests on swift-evolution, there seem to be many, many implemented proposals stuck in a similar limbo.

  1. map sorting (open since march 7th, implementation: apple/swift#23156)

  2. where clauses on contextually generic declarations (open since april 1, implementation: apple/swift#23489)

  3. character literals (open since june 13, implementation: apple/swift#21873)

  4. add isPower(of:) to BinaryInteger (open since may 30, implementation: apple/swift#24766)

  5. add reduce(_:) to Sequence (open since january 10, implementation: apple/swift#21767)

  6. consistent lazy API (open since january 7, implementation: apple/swift#21793)

these are only a sampling of examples from 2019, the backlog extends far beyond this list. failing to act on these ready proposals has real consequences: code rot means lots of the implementations now have merge conflicts with the swift master branch, returning (not just potential!) contributors are discouraged from contributing to swift again, and the lack of responsiveness displayed by the swift team reflects badly on the open source project as a whole.

the swift project should not be expected to accept any and all contributions just because a random contributor submitted a pull request. however, as an open source project, it is a basic expectation that those responsible for managing the project should give a fair hearing to such contributions, even if it amounts to a simple explanation for why the contribution was thrown out. If they lack the time or resources to do so, it is their responsibility to relinquish control of the project to the community or a more decentralized authority that is capable of reciprocating the effort that community contributors have given to the project. if community contributions are only looked at whenever the apple team “feels like it”, then swift is not a true open source project, and marketing it as such is disingenuous.

i have made tons of attempts to resolve this matter privately, including DMing both non-core and multiple core team members and bumping the pull request, and i feel i, and others, have given ample time for someone, (anyone!) to “get around to it”. however my attempt to contact the core team privately did not even garner a response, and at this point i feel like i have no choice but to raise this issue publicly.

Why are all these proposals not being acted upon?

32 Likes
2

Hi Kelvin,

You are right to flag the lack of transparency here. I apologize for my part in that. We should respond as a core team officially to each of these. Putting this official response together has been a long-standing to-do for the core team, and has ended up being pushed out in favor of the more urgent task of wrapping up the recent release.

In the short term, here is my own personal non-official feedback on why some of these proposals are currently in a holding pattern. I'll group them together, and fold in a couple of additional ones to help flesh out the narrative a little.

Previewing Mechanism and ABI considerations

This applies to most of the std lib proposals (and incidentally, is why I labelled those PRs on GitHub, so one could see just that subset). I recently pitched a new way of adding to the standard library by first previewing in a package. In my view, agreeing on this mechanism is probably the first thing that needs to be done before we make further substantial additions to the standard library. Now that we have an ABI, that ABI is forever and it increases the level of care we take in making additions.

I'd put the proposal to chunk a sequence into this bucket. (It's such a good proposal we have two :slight_smile: something that is also a cause for a PR stalling...). This is definitely a non-trivial problem to solve lazily (the preferred way to solve it for collections) but since it introduces a type, it'd be really good to get some real-world use and feedback before it's locked into the ABI.

Technical Blockage

A couple of proposals are unfortunately blocked by the requirement to mark conformances with availability. Specifically the lazy and zip proposals. These are IMO very well merited proposals that are in some way almost bug fixes, but need to wait until the availability issue is resolved. It's a good question whether the PRs should be closed in the mean-time as inactionable, or left open.

More Thought Needed

There a few proposals where the main blocker is that they need more time and consideration before they're ready to review. Perhaps more time or input in the pitch phase, or more thorough alternatives considered. You bring up the character literals proposal: that's an excellent example of a proposal where it did come to review, and in hindsight this was a mistake, because there was much about the original proposal that was just not ready for review. It's important we not make that mistake a second time.

There are other examples where what is being proposed is a fairly narrow targeted addition, where what we need instead is a more holistic survey of the problem space. I would put map sorting into this bucket. It sugars some use cases, but does not address others (such as sorting by multiple criteria, or partial sorting). Ideally, when this is the case, instead of targeted proposals, there would be a full survey of the problem space from which a series of proposals fall out. This way we can be confident that the final set of APIs relating to sorting are consistent and composable because they've all been designed together, fully cover the problem space etc.

Given the place we are in within the release cycle, now would be a perfect time to do this kind of thing. Especially now we are post-ABI stability and less constrained in terms of additions to the standard library. And again, resolving the approach to previews is key here, in order to ensure there is a real-world feedback cycle involved before they're finalized.

Trivial Additions

A large number of the additions being proposed are trivially composable. This is a topic that has come up quite a few times. We've given fairly clear guidance in the past that trivially composable functions are not something that generally make for good proposals: that proposals need to instead be targeted at solving difficult but common problems, or help resolve a serious correctness or performance issue.

Despite this, we've not seen many proposals that truly fulfill the criteria for addition. Instead, we continue to get many trivially composable proposals, but coupled with thin justifications of why they fulfill the other criteria. For example, the fold1 version of reduce has a justification on the basis of correctness: that if you are multiplying rather than summing a sequence you might supply 0 instead of 1 for the initial value by accident. This is really stretching the bounds of avoiding correctness issues beyond its breaking point, as I don't think it can be reasonably argued that this is ever a problem.

There's a real risk if only trivial proposals are reviewed and accepted that we end up with a severely lop-sided standard library that only has nice-to-have functions in it. This would lead to a very frustrating experience when hunting through looking for the harder algorithms.

I think it's a good discussion point as to how we solve this problem. Clearly informal steering advice isn't working. The core team could start to just close PRs more aggressively, and give official direction during the pitch phases that something won't make it to review, but this seems pretty heavy handed. One idea I think might work is to put together a list of "missing" more-substantial additions that need to be worked on, and steer prospective proposers towards that. Once we have this, and we start to progress through it, that would relieve the pressure to push back on useful-but-simple proposals, because the risk of a lop-sided library would lessen. @nnnnnnnn has been looking at doing this recently. But you'll have to bear with him, as that in itself is a task that takes time.

24 Likes
3

I had similar experience with swift-corelibs-foundation. Last year I spent few hours to implement and contribute missing parts in URLResource, Stream and NSCoding and had made few pull requests, but I did not get adequate feedback by team members nor they were merged or closed. Now it seems functionalities are implemented by Apple members and those PRs are non-relevant by now and should be closed.

I didn't make more contribution after that as I think reviewing and giving positive/negative feedbacks are essential part of an open-source project.

11 Likes
4

to me this seems like closing the highway before you’ve even put out the orange detour cones. the standard library preview package is a great idea, but we can’t just shut down all of swift evolution for however many months it takes to make that one feature a thing. minimizing disruption to the wider project is important.

that makes sense. but is it too much effort to add a github tag and a link to an open issue to the pull request instead of leaving it on read? small gestures like these mean a lot.

the “pitch phase” usually ends when the pitch thread goes cold, meaning people have stopped commenting on it. this is a sign that anyone who might have had input or possible alternatives for the proposal has already shared those insights, and the author has already incorporated or refuted that feedback. throwing “more time” at the pitch thread or canvassing people who aren’t interested in discussing a particular topic is unlikely to conjure up any fresh thoughts, so i really don’t know what solution you’re proposing for this problem. if a thread hasn’t seen any activity for 72 days, slapping another 3 months on the clock isn’t going to help.

if you ask me, we have the opposite problem, which is someone pitches a simple, easily understandable, useful addition to the language,, and then the PL theorists punt to the most general, abtruse, overengineered framework that promises to take care of everything and will likely get done never. it’s impossible to have a discussion about small gaps in the language like vector/matrix types without someone bringing up variadic generics, despite the fact that no one really has any clue how variadic generics in swift would actually work, other than agreeing that we “need them” in the typical vague, intellectually lazy manner. variadic generics, generalized existentials, and arbitrary-precision booleans are the single-payer of language design — people drop the concepts as buzzwords to ward off any actual solutions for the problem at hand. if we’re being honest it’s just another form of collective developer procrastination.

Taking synthesized Comparable as an example, there were people who were like “why can’t this be part of a fully generalizable standard library code generation framework that could even be customizable by the user?”. never mind though that no one really has any idea what “MemberIterable”, much less total metaprogramming in swift would even look like, or how it would work, and most importantly, if it would even be that useful. (enums remember, don’t have stored members to begin with, they have cases, which are a whole different animal.)

i completely agree with you

12 Likes
5

Given that a core team member coauthored the C++ variadic templates proposal, I think at least one person has a clue how variadic generics would work.

20 Likes
6

i think if there was that much consensus around lifting the variadics design from c++, we would not have been going around and around this subject for this many years, and there would not be a dozen evolution threads on the topic which mostly rehash the same old questions. basic features like 2,3,4-vectors and matrices would not have been hung up since 2016.

lemme put it this way: maybe individual people, even people with considerable influence might have a clue how variadics would work in their own imagination, but it’s pretty clear that collectively, we don’t.

3 Likes
7

Let's not lose sight of the goal: to create a good and sustainable language/library. The Swift Evolution process is a means to do this, not an end in itself.

If the backed up stack of evolution proposals looked to have a transformative effect on the language, then holding them up would be bad, because we will go multiple releases without these transformative improvements. But let's be honest: most of the proposals we are talking about here are minor, and the opportunity cost of waiting for a process that guarantees the end result when they finally land is therefore low. The way to make a compelling case that we must move forward more urgently is to make more compelling proposals.

A pitch thread quiescing is necessary, but not sufficient, for a proposal to move to review. You are right that doing nothing more than leaving the pitch open doesn't do much. But that doesn't mean all you need to do is pitch something, wait out the feedback, and then you're clear to request a review. Some of the currently open PRs had feedback in pitch that suggests they need a rethink or possibly withdrawal, but they remain open and unmodified. Again, it would be good to not have to rely on heavy intervention from the core team to ensure this happens.

These two problems are not mutually exclusive. We can both have trivial proposals we shouldn't run and have people suggesting over-engineered alternative solutions. That said, your tone seems a way too antagonistic here, and is likely to be dismissing some very real concerns with moving forward too tactically.

13 Likes
8

then these PRs should be closed after a set amount of time, and the proposals sent back to the drawing board. otherwise you get this weird disconnect where the core team thinks the problem is a dealbreaker and has no intention of accepting it as-is, while the author thinks the problem is tolerable and they just have to wait for more reviewer opinions to trickle in due to the very informal nature of the whole process. authors (at least me) are pretty aware that there are certain participants in swift evolution who don’t feel like they’ve properly reviewed a pitch if they haven’t thought of at least one complaint. (and there’s nothing wrong with that.) it would be good if authors got better feedback about exactly what is wrong with a proposal, and how severe it is.

sorry about that. forums are not a good medium for these kinds of conversations

10 Likes
10

I’m not sure, but are these issues with the PRs being communicated back to the proposers for why they’re in a holding pattern?

I’ve personally avoided contributing to the swift evolution process beyond comments because the acceptance criteria for proposals/work seems quite opaque.

My impression has tended to be that there is a certain “inner sanctum” of proposers who’s work seem almost sure to come to review, and everyone else it appears has a much harder time of getting proposals to review, much less into production.

Some of this stems from the fact there is a core team and this is an internal project that has been somewhat opened up, with a large chunk of investment and control still in Apple’s hands. Add to that Apple dropping proposals practically in sync with WWDC, and sending them directly into review (after already stating to the public that they will be accepted, at least in some form), and it just adds to the impression that this is a mere token gesture of openness.

It makes it very discouraging to make contributions when the investment of time and effort may be a waste, and we have no way of knowing, because at least from the outside, all we see is PRs open for months on end with practically no open communication about their status, and the only exceptions are from Apple, or a handful of external devs.

15 Likes
11

Thanks for the thoughts Ben. Most of what you’ve said for reasoning makes good sense, so the real issue is a lack of timely feedback — even if the feedback is, “this one will never happen — too trivial” or “good pitch. Won’t go to review until is resolved”.

3 Likes