# Should Proposals Include a "Limitation of Future Evolution" Section

**URL:** <https://forums.swift.org/t/should-proposals-include-a-limitation-of-future-evolution-section/22646>\
**Category:** Discussion\
**Created:** [April 4, 2019, 3:24pm UTC](https://forums.swift.org/t/should-proposals-include-a-limitation-of-future-evolution-section/22646 "2019-04-04T15:24:14Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![mattrips](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/mattrips/32/4079_2.png) [@mattrips](https://forums.swift.org/u/mattrips)\
**Post date:** [April 4, 2019, 3:24pm UTC](https://forums.swift.org/t/should-proposals-include-a-limitation-of-future-evolution-section/22646/1 "2019-04-04T15:24:14Z")

</div>

Sometimes, changes to Swift can be limiting on future evolution. For instance, see [the pitch to elide commas](https://forums.swift.org/t/pitch-eliding-commas-from-expression-lists/22558/6).

So, should a discussion of the potential effect on future evolution be a _standard_ component of a proposal?

I think, yes. Authors should consider the potential limitations, and discuss the same as part of their proposals. Reviewers should consider the same.

Usually, this discussion happens as a natural part of a proposal review, but it may deserve more emphasis. Making this discussion a _standard_ component of a proposal, perhaps under the heading "Limitation of Future Evolution," would bring it to the fore.

---

<div class="post-metadata">

**Author:** ![jawbroken](https://avatars.discourse-cdn.com/v4/letter/j/cc9497/32.png) [@jawbroken](https://forums.swift.org/u/jawbroken)\
**Post date:** [April 5, 2019, 12:12am UTC](https://forums.swift.org/t/should-proposals-include-a-limitation-of-future-evolution-section/22646/2 "2019-04-05T00:12:15Z")

</div>

I think brevity is a virtue, so I'm not sure it needs to be a standard component. It's always easy to see the benefit of adding new sections to the proposal template (encourages thought about more aspects of the design) but there are downsides too (takes up more time for both proposal writers and reviewers). Perhaps there could be some conditional sections, though (e.g. for proposals that change or add syntax, versus things like standard library additions).

---

<div class="post-metadata">

**Author:** ![mattrips](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/mattrips/32/4079_2.png) [@mattrips](https://forums.swift.org/u/mattrips)\
**Post date:** [April 5, 2019, 3:44am UTC](https://forums.swift.org/t/should-proposals-include-a-limitation-of-future-evolution-section/22646/3 "2019-04-05T03:44:10Z")

</div>

Good points. Thanks for taking interest.

Sometimes, too much "process" can be detrimental. The current system works.

And, yes, I suppose certain classes of change warrant extra attention on this front, while others might not.

---

<div class="post-metadata">

**Author:** ![Avi](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/avi/32/2962_2.png) [@Avi](https://forums.swift.org/u/Avi)\
**Post date:** [April 5, 2019, 4:19am UTC](https://forums.swift.org/t/should-proposals-include-a-limitation-of-future-evolution-section/22646/4 "2019-04-05T04:19:27Z")

</div>

I think it would place an undue burden on proposal authors. Very few people are familiar with the ins-and-outs of the compiler, and even fewer are computer scientists. Having an idea for improvement in one area does not imply knowledge sufficient to foresee issues with other not-even-yet-proposed ideas.

"Prediction is very difficult, especially if it’s about the future."

---

<div class="post-metadata">

**Author:** ![mattrips](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/mattrips/32/4079_2.png) [@mattrips](https://forums.swift.org/u/mattrips)\
**Post date:** [April 10, 2019, 6:11am UTC](https://forums.swift.org/t/should-proposals-include-a-limitation-of-future-evolution-section/22646/5 "2019-04-10T06:11:46Z")

</div>

As a general matter, I agree with that sentiment. However, the people guiding the evolution of a computer programming language ought to be, or rely upon the advice of, computer scientists. Somebody needs to do the hard work of thinking into the future. Certainly, the authors of a proposal, if not able to do that work themselves, ought to seek out that sort of help at the pitch stage, and then include the results as part of the proposal.

---

<div class="post-metadata">

**Author:** ![mattrips](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/mattrips/32/4079_2.png) [@mattrips](https://forums.swift.org/u/mattrips)\
**Post date:** [April 10, 2019, 6:16am UTC](https://forums.swift.org/t/should-proposals-include-a-limitation-of-future-evolution-section/22646/6 "2019-04-10T06:16:36Z")

</div>

The pitch that motivated this discussion is now a proposal. Surprisingly, the proposal does not include a discussion of potential limitations on future evolution _even though the same were discussed in the pitch thread._ My [post](https://forums.swift.org/t/se-0257-eliding-commas-from-multiline-expression-lists/22889/42) on the proposal review thread addresses this point at greater length.

---

<div class="post-metadata">

**Author:** ![Avi](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/avi/32/2962_2.png) [@Avi](https://forums.swift.org/u/Avi)\
**Post date:** [April 10, 2019, 6:21am UTC](https://forums.swift.org/t/should-proposals-include-a-limitation-of-future-evolution-section/22646/7 "2019-04-10T06:21:13Z")

</div>

I agree that those who have insight should offer it, and I agree that such insight should inform the proposal. I am not certain that there's benefit to requiring a section that most pitch authors would not be able to fill properly. Would we be OK if proposal authors simply entered _I can't think of any_ under the heading?

We don't accept such reasoning for the sections on API/ABI stability, and rightly so. Those sections impact the language as it is today. A section on limits to evolution is about changes that may never occur.

I have not seen any indication that the core team is not cognizant of this issue when they make their determination. Commenters are free to bring up points that the core team may not have thought of, and this happens on a regular basis. My own opinion is that this is sufficient.

---

<div class="post-metadata">

**Author:** ![mattrips](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/mattrips/32/4079_2.png) [@mattrips](https://forums.swift.org/u/mattrips)\
**Post date:** [April 10, 2019, 7:48am UTC](https://forums.swift.org/t/should-proposals-include-a-limitation-of-future-evolution-section/22646/8 "2019-04-10T07:48:29Z")

</div>

Certainly, this question is not implicated by most proposals. But, where it is implicated, it seems nonsensical to engage in a discussion about the proposal without insight from those who best understand the implication. Without that insight, the review process is uninformed.

Highlighting the question of future evolution in the proposal template would be helpful. Mandating that it be addressed would be prudent. The burden on authors of most proposals would be slight:

> **Potential Impact on Future Evolution**  
> Not aware of any. None mentioned in discussion and pitch threads.
