<table><tr><td style="">apol added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D6355" rel="noreferrer">View Revision</a></tr></table><br /><div><div><blockquote style="border-left: 3px solid #8C98B8;
          color: #6B748C;
          font-style: italic;
          margin: 4px 0 12px 0;
          padding: 8px 12px;
          background-color: #F8F9FC;">
<div style="font-style: normal;
          padding-bottom: 4px;">In <a href="https://phabricator.kde.org/D6355#119988" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: none;" rel="noreferrer">D6355#119988</a>, <a href="https://phabricator.kde.org/p/kossebau/" style="
              border-color: #f1f7ff;
              color: #19558d;
              background-color: #f1f7ff;
                border: 1px solid transparent;
                border-radius: 3px;
                font-weight: bold;
                padding: 0 4px;" rel="noreferrer">@kossebau</a> wrote:</div>
<div style="margin: 0;
          padding: 0;
          border: 0;
          color: rgb(107, 116, 140);"><p>Usually I have some motivation to (re-)implement some certain virtual method (e.g. following a tutorial or documentation), and then I know already the name and also might not really care if the base method is abstract or not, that is a minor detail similar to constness.<br />
 Having to scan two separate lists possibly to find the method will mean extra time spent on many occasions without too much gain.</p></div>
</blockquote>

<p>I don't think that's true by far. Leaf classes are obviously more common and it makes sense just to declare them as soon as possible. Note that override entries will disappear as soon as they're already overriden.</p>

<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>Not sure autocompletion should be used for that.</p></blockquote>

<p>It's been like this since early KDevelop 4, I wouldn't change it now, especially not with the current state where the abstract ones are just hidden.</p>

<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>That aside, "Abstract Override" as term should see some more thinking, at least in Scala this has a different meaning :) No better proposal right now myself.</p></blockquote>

<p>Do you have a proposal? Otherwise it's just bit-rotting...</p>

<p>Personally, I just see this as a regression from switch to clang.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R32 KDevelop</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D6355" rel="noreferrer">https://phabricator.kde.org/D6355</a></div></div><br /><div><strong>To: </strong>apol, KDevelop, kfunk<br /><strong>Cc: </strong>kossebau, kdevelop-devel<br /></div>