<div class="markdown">
<h2>What is your evaluation of the proposal?</h2>

<p dir="auto">I vote -1 on the proposal as submitted. First of all, while I do appreciate the effort that went into writing the proposal, having read the whole document I still don't understand (i) exactly what problem is being solved here and (ii) why abstract classes are the necessary solution to those problems. This might just be a function of my lack of knowledge, but considering that this proposal is trying to extend the language with a significant new concept, I think the burden should be on its author to analyze the problem, sketch out a space of possible solutions to the problem as analyzed, weight these solutions against one another by examining each of their consequences, and demonstrate why the proposed solution is the best possible option in light of the alternatives.</p>

<h2>If you have used other languages or libraries with a similar feature, how do you feel that  this proposal compares to those?</h2>

<p dir="auto">To put my cards on the table -- while I do acknowledge their utility I'm not a big fan on abstract classes. I think they're an ad-hoc solution to a deep problem that benefits from a more principled approach. </p>

<p dir="auto">Here's my best attempt at a breakdown. In my view, if classes give programmers a concise way to specify a data structure, its interface, and its implementation in an open, hierarchically extensible fashion, abstract classes give programmers a concise way to <em>partially</em> specify a data structure, its interface, and its implementation in an open, hierarchically extensible fashion. </p>

<p dir="auto">The issue I have with abstract classes is that there are much better, more principled ways to solve the problem of partial specification of an data structure / interface implementation in an extensible fashion (mixins, in particular, which I understand to be more or less protocols-with-storage that introduce a subtyping relationship with anything that mixes them in). Abstract classes are a convenient, nearly inevitable, and actually pretty decent incremental extension of the object-oriented paradigm. But when you break out the deep problems abstract classes are meant to solve, they emerge (in my opinion) as incomplete, limited, and ultimately unhelpful despite their utility.</p>

<p dir="auto">The main reason for this is that they lock users into hierarchical inheritance (and hierarchical thinking) when it isn't needed, it isn't efficient, and it isn't as flexible as it could be. The flexibility afforded by mixins (especially if mixins themselves could inherit from and extend one another) would allow the user to reuse code in far more ways that abstract classes currently do. It would allow functionality to be factored out in all of the clever ways protocol extensions currently allow but without the storage-related limitations.</p>

<h2>Is the problem being addressed significant enough to warrant a change to Swift?</h2>

<p dir="auto">I'm not sure, partially because having read the proposal I'm still not clear exactly what the problem is. While I have on occasion missed something like abstract classes in Swift, that itch has always been minor, and it is often an indication that my architecture could use a good rethink. On top of that, as I outlined above, mixins have always seemed to me like a strictly more powerful solution to the same problem solved by abstract classes. I'd be willing to wait for protocols / protocol extensions to gain the ability to add storage to the structs and classes that adopt them.</p>

<h2>Does this proposal fit well with the feel and direction of Swift?</h2>

<p dir="auto">I don't think so, for the reasons above.</p>

<h2>How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</h2>

<p dir="auto">I read the whole proposal once and have followed the discussion a little bit.</p>

</div>