# The role of vision documents in Swift evolution

**URL:** <https://forums.swift.org/t/the-role-of-vision-documents-in-swift-evolution/62101>\
**Category:** Announcements\
**Tags:** swift-evolution, visions\
**Created:** [December 17, 2022, 6:29am UTC](https://forums.swift.org/t/the-role-of-vision-documents-in-swift-evolution/62101 "2022-12-17T06:29:12Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![Paul\_Cantrell](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/paul_cantrell/32/16764_2.png) [@Paul\_Cantrell](https://forums.swift.org/u/Paul_Cantrell)\
**Post date:** [December 19, 2022, 8:57pm UTC](https://forums.swift.org/t/the-role-of-vision-documents-in-swift-evolution/62101/2 "2022-12-19T20:57:12Z")

</div>

This post brought me back. Ages ago, in the olden days when swift-evolution was a mailing list and dinosaurs roamed the earth — i.e 2017 — I expressed concern about the strictly incremental nature of the SE process:

> [@Swift phases and mis-timed proposals](https://forums.swift.org/t/swift-phases-and-mis-timed-proposals/6098/11):
>
> This touches on two related concerns I’ve long had about how swift-evolution has worked so far.
> 
> Concern #1 is that we consider proposals in relative isolation, on their own merits. That’s understandable and wise. Without this focus, we’d never reach conclusions about anything. However, this does tilt the process toward greedy optimization as we traverse the language space. I worry that there’s not enough attention to the big picture.
> 
> Concern #2 is that it’s hard to know what to do with a proposal when the ideal answer is “we need to see how it plays out in practice and then decide whether to accept it.” Theoretical discussion untempered by practical prototyping is a great way for a group to talk itself into a bad idea. (This will especially be a problem with future work to build out generics & existentials.)
> 
> …
> 
> The net result is that IMO we tend to over-favor narrow solutions that solve very specific problems, and under-favor simpler, more general features that are good-enough solutions to _many_ problems at once — not as nice for any _one_ of those problems in isolation, but nicer to work with taken as a whole.

(Ted Kremenek agreed in response that [“some of the proposals have felt like steps of a hill-climbing algorithm”](https://forums.swift.org/t/swift-phases-and-mis-timed-proposals/6098/14), which I thought was wall said.)

It’s satisfying to reflect on how far the process has come since then.

I was worried about the “proposals must have implementations” requirement, but that has borne tremendous fruit: sharper, better-written proposals with a better understanding of quirks, corner cases, and tradeoffs, and far less backtracking in the evolution process.

And contrary to my concerns about the evolution process tending toward “greedy optimization,” Swift has successfully undertaken large-scale evolutions that require holistic design thinking about many interlocking proposals: concurrency, bringing much-needed generality to the generic type system, and now ownership control…the list goes on.

Manifestos played a crucial role in all of that work. Officially bringing them into the fold as vision documents feels like closing the loop on my 2017 concerns. Both my concerns in that old post are well addressed. We have not only a better language than we did 5 years ago, but a better process for evolving it.

No concerns or criticism here, just appreciation for the people who’ve brought Swift so far over the years. It has been a true community effort, and it’s heartening to see a community effort succeed.

---

_[View the full topic](https://forums.swift.org/t/the-role-of-vision-documents-in-swift-evolution/62101)._