Should Proposals Include a "Limitation of Future Evolution" Section

(Matt Rips) #1

Sometimes, changes to Swift can be limiting on future evolution. For instance, see the pitch to elide commas.

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.


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

(Matt Rips) #3

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.


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

(Matt Rips) #5

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.

(Matt Rips) #6

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 on the proposal review thread addresses this point at greater length.


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.

(Matt Rips) #8

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.