<html><head><style>
body {
font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;
padding:1em;
margin:auto;
background:#fefefe;
}
h1, h2, h3, h4, h5, h6 {
font-weight: bold;
}
h1 {
color: #000000;
font-size: 28pt;
}
h2 {
border-bottom: 1px solid #CCCCCC;
color: #000000;
font-size: 24px;
}
h3 {
font-size: 18px;
}
h4 {
font-size: 16px;
}
h5 {
font-size: 14px;
}
h6 {
color: #777777;
background-color: inherit;
font-size: 14px;
}
hr {
height: 0.2em;
border: 0;
color: #CCCCCC;
background-color: #CCCCCC;
display: inherit;
}
p, blockquote, ul, ol, dl, li, table, pre {
margin: 15px 0;
}
a, a:visited {
color: #4183C4;
background-color: inherit;
text-decoration: none;
}
#message {
border-radius: 6px;
border: 1px solid #ccc;
display:block;
width:100%;
height:60px;
margin:6px 0px;
}
button, #ws {
font-size: 12 pt;
padding: 4px 6px;
border-radius: 5px;
border: 1px solid #bbb;
background-color: #eee;
}
code, pre, #ws, #message {
font-family: Monaco;
font-size: 10pt;
border-radius: 3px;
background-color: #F8F8F8;
color: inherit;
}
code {
border: 1px solid #EAEAEA;
margin: 0 2px;
padding: 0 5px;
}
pre {
border: 1px solid #CCCCCC;
overflow: auto;
padding: 4px 8px;
}
pre > code {
border: 0;
margin: 0;
padding: 0;
}
#ws { background-color: #f8f8f8; }
.bloop_markdown table {
border-collapse: collapse;
font-family: Helvetica, arial, freesans, clean, sans-serif;
color: rgb(51, 51, 51);
font-size: 15px; line-height: 25px;
padding: 0; }
.bloop_markdown table tr {
border-top: 1px solid #cccccc;
background-color: white;
margin: 0;
padding: 0; }
.bloop_markdown table tr:nth-child(2n) {
background-color: #f8f8f8; }
.bloop_markdown table tr th {
font-weight: bold;
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
.bloop_markdown table tr td {
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
.bloop_markdown table tr th :first-child, table tr td :first-child {
margin-top: 0; }
.bloop_markdown table tr th :last-child, table tr td :last-child {
margin-bottom: 0; }
.bloop_markdown blockquote{
border-left: 4px solid #dddddd;
padding: 0 15px;
color: #777777; }
blockquote > :first-child {
margin-top: 0; }
blockquote > :last-child {
margin-bottom: 0; }
code, pre, #ws, #message {
word-break: normal;
word-wrap: normal;
}
hr {
display: inherit;
}
.bloop_markdown :first-child {
-webkit-margin-before: 0;
}
code, pre, #ws, #message {
font-family: Menlo, Consolas, Liberation Mono, Courier, monospace;
}
.send { color:#77bb77; }
.server { color:#7799bb; }
.error { color:#AA0000; }</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="bloop_markdown"><p>Abstract classes would introduce even more awkward complexity to the current metatype model of Swift (so do I believe). Abstract classes are like existentials right? ATM we’ve got the problem with <code>T.Type</code> vs. <code>T.Protocol</code> which is clumsy. Abstract classes might introduce <code>T.Class</code> or even used as <code>T.Protocol</code>, which would be really strange.</p>
<p>We’re still waiting for our proposal to get re-scheduled into the evolution review to fix metatypes: <a href="https://github.com/DevAndArtist/swift-evolution/blob/cd9d8b3f1923d16f4381c23d3d335d88d83e32cd/proposals/0126-refactor-metatypes.md">Refactor Metatypes Proposal</a></p>
<p></p></div><div class="bloop_original_html"><style>body{font-family:Helvetica,Arial;font-size:13px}</style><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div> <br> <div id="bloop_sign_1480693607522585856" class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">-- <br>Adrian Zubarev<br>Sent with Airmail</div></div> <br><p class="airmail_on">Am 2. Dezember 2016 um 16:45:03, Benjamin Spratling via swift-evolution (<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>) schrieb:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>I see where you're going with that. So it's an artifact from Java and C++, too? :)<br><br>I was recently doing a review of music notation, and one of the problems is that it has multiple ways of doing exactly the same thing. Anyone trying to read a given piece of music has to learn all of them, making the problem multiple times harder than necessary.<br><br>We already have a way to enforce "you need to implement this" in Swift, and it's with protocols. Personally, I'd rather see us move in that direction.<br><br>-Ben<br><br>Sent from my iPhone.<br><br>> On Dec 2, 2016, at 9:36 AM, Jeremy Pereira <jeremy.j.pereira@googlemail.com> wrote:<br>> <br>> <br>>> On 2 Dec 2016, at 14:07, Benjamin Spratling via swift-evolution <swift-evolution@swift.org> wrote:<br>>> <br>>> I agree that there is a major problem with “subclasses must override these methods”. We have no capability to describe this in Swift, and frankly, it feels like something that ought to be enforced. It’s almost like we were really asked to conform to a protocol, but the protocol was a class. Maybe this is an artifact from previous Obj-C development? I.E. if it were designed in scratch in Swift it wouldn’t be a class with required overrides, but a protocol where every other method already had a default implementation?<br>> <br>> In Java and C++ you would implement this with an abstract method. i.e. a method that has a declaration and no body. A proposal was made to introduce these but was deferred. Reading the rationale for the decision, it looks like the dev team were generally favourable but didn’t have time to do the implementation, plus there were some details that needed to be nailed down.<br>> <br>> https://github.com/apple/swift-evolution/blob/master/proposals/0026-abstract-classes-and-methods.md<br>> <br>>> <br>> <br>>>> One of the simple examples would be: you need an API that requires overriding? Make it accessible for ancestors only (even in protocols). Despite the argument "ancestors can open it to public" (there are a lot of dangerous things to do) it makes the API much more clean and hides implementation complexity. Otherwise you just have to explain it in the doc "please don't call this method, it's an internal" which feels wrong.<br>>> _______________________________________________<br>>> swift-evolution mailing list<br>>> swift-evolution@swift.org<br>>> https://lists.swift.org/mailman/listinfo/swift-evolution<br>> <br>_______________________________________________<br>swift-evolution mailing list<br>swift-evolution@swift.org<br>https://lists.swift.org/mailman/listinfo/swift-evolution<br></div></div></span></blockquote></div><div class="bloop_markdown"><p></p></div></body></html>