Pitch to Proposal process

[taylorswift]

@GalCohen

I'm seeing a lot of good pitches (at least ideas in early stage, before a proper proposal) that generate a lot of interest and discussion on their threads but eventually the conversation dies down, or they get buried by other more recent / frequently commented threads.

i’d go so far as to say this stage of the swift evolution process is fundamentally broken. it’s way too dependent on the specific person who pitched the idea in the first place, and if the person isn’t aggressive enough to drive it forward, it basically dies. if the person isn’t politically savvy enough to get the proposal to win in the review phase, it and all similar ideas get shut out forever under the whole “this has already been rejected” rationale.

i went through some of the topics I started in the past that got at least some support or generated some discussion:

• Enums with “cooked” values - #3 by DevAndArtist

• Referring to failable initializer with leading dot syntax

• Namespacing protocols to other types - #14 by taylorswift

• Loading misaligned values from raw buffers

• Namespaces × submodules - #57 by DevAndArtist

• Synthesizing Equatable, Hashable, and Comparable for tuple types - #65 by John_McCall

There’s also the huge thread

• TrigonometricFloatingPoint/MathFloatingPoint protocol? - #90 by taylorswift

though it seems like other people are starting to take up swords on this since there’s been a lot of interest in “swift numerics” recently.

One thing that seems common to a lot of these dead pitches is people like to punt the pitch to some handwavium feature X and say “well we should really wait until we have X in the language” or “this won’t be a problem once we have X” at the expense of real, concrete solutions to the immediate problem. “Variadic Generics” seems to be a common excuse i hear a lot. @compilerEvaluable is another.

Another issue i’ve noticed is a lot of people like to point out corner cases or poorly-defined semantics in parts of a pitch, but offer no potential solutions or answers. This is a great way to kill a proposal through confusion and uncertainty.

Some things I think would make a good starting point for fixing this process would include

• a well defined timetable for moving pitches to proposals, and then review. right now everything moves at the pace of “whenever so-and-so feels like it”, which most often translates to “never”.

• discouraging mission creep and discouraging people from trying to connect small problems that have feasable solutions to larger intractable, structural issues with the language.

• making it a policy that anyone who asks a question about the semantics of a pitched feature, should propose a definition for those semantics.

• create a “retry” pathway to advance good ideas that failed in review because the original proposal author lacked the political skill to get the support the proposal needed.