Why are these evolution proposals not moving forward?

[taylorswift]

@Ben_Cohen

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 :) 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.

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.

@Ben_Cohen

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.

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.

@Ben_Cohen

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.

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.

@Ben_Cohen

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.

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.)

@Ben_Cohen

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.

i completely agree with you