On 2013-09-10 02:28, Andrei Alexandrescu wrote:

> After I've seen a pretty cool demo of clang-modernize
> (http://clang.llvm.org/extra/ModernizerUsage.html), I think the best way
> to attack this and similar problems is to add a class hierarchy
> analyzer: a command-line utility that is fed an entire project and adds
> as many 'final' as possible without changing semantics.
>
> Time has come to migrate such functionality to tools. We keep on telling
> that "nobody uses the tools" but it seems experience contradicts that
> belief.

I completely agree. But then again, we need a D front end for this.

-- 
/Jacob Carlborg

On Tuesday, 10 September 2013 at 00:28:24 UTC, Andrei Alexandrescu wrote:
> On 9/9/13 12:47 PM, H. S. Teoh wrote:
>> On Mon, Sep 09, 2013 at 09:37:07PM +0200, Namespace wrote:
>>> It's been a while since Manu convinced Walter and Andrei to
>>> introduce a virtual Keyword and to change the default from virtual
>>> methods to final methods.
>>> Anything new? Anybody working on that? I would love to see that
>>> soon.
>>
>> This is going to break a lot of code. We'd need some kind of deprecation
>> path. And even then, it may anger a lot of existing users.
>>
>>
>> T
>
> After I've seen a pretty cool demo of clang-modernize (http://clang.llvm.org/extra/ModernizerUsage.html), I think the best way to attack this and similar problems is to add a class hierarchy analyzer: a command-line utility that is fed an entire project and adds as many 'final' as possible without changing semantics.
>
> Time has come to migrate such functionality to tools. We keep on telling that "nobody uses the tools" but it seems experience contradicts that belief.
>
>
> Andrei

Does it mean that we have to delay the change (virtual by default -> final by default) somewhat, but still introduce the virtual keyword?
Or does it mean that nothing is introduced and everything stays as it is?

On Tue, 10 Sep 2013 02:28:24 +0200, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 9/9/13 12:47 PM, H. S. Teoh wrote:
>> On Mon, Sep 09, 2013 at 09:37:07PM +0200, Namespace wrote:
>>> It's been a while since Manu convinced Walter and Andrei to
>>> introduce a virtual Keyword and to change the default from virtual
>>> methods to final methods.
>>> Anything new? Anybody working on that? I would love to see that
>>> soon.
>>
>> This is going to break a lot of code. We'd need some kind of deprecation
>> path. And even then, it may anger a lot of existing users.
>>
>>
>> T
>
> After I've seen a pretty cool demo of clang-modernize (http://clang.llvm.org/extra/ModernizerUsage.html), I think the best way to attack this and similar problems is to add a class hierarchy analyzer: a command-line utility that is fed an entire project and adds as many 'final' as possible without changing semantics.
>
> Time has come to migrate such functionality to tools. We keep on telling that "nobody uses the tools" but it seems experience contradicts that belief.

So the catastrophe that is virtual by default will not be changed?

-- 
Simen

On Tuesday, September 10, 2013 11:27:40 Simen Kjaeraas wrote:
> On Tue, 10 Sep 2013 02:28:24 +0200, Andrei Alexandrescu
> 
> <SeeWebsiteForEmail@erdani.org> wrote:
> > On 9/9/13 12:47 PM, H. S. Teoh wrote:
> >> On Mon, Sep 09, 2013 at 09:37:07PM +0200, Namespace wrote:
> >>> It's been a while since Manu convinced Walter and Andrei to
> >>> introduce a virtual Keyword and to change the default from virtual
> >>> methods to final methods.
> >>> Anything new? Anybody working on that? I would love to see that
> >>> soon.
> >> 
> >> This is going to break a lot of code. We'd need some kind of deprecation path. And even then, it may anger a lot of existing users.
> >> 
> >> 
> >> T
> > 
> > After I've seen a pretty cool demo of clang-modernize (http://clang.llvm.org/extra/ModernizerUsage.html), I think the best way to attack this and similar problems is to add a class hierarchy analyzer: a command-line utility that is fed an entire project and adds as many 'final' as possible without changing semantics.
> > 
> > Time has come to migrate such functionality to tools. We keep on telling that "nobody uses the tools" but it seems experience contradicts that belief.
> 
> So the catastrophe that is virtual by default will not be changed?

AFAIK, no official decision has ever been made. It seemed like Walter was convinced that it was worth it to make non-virtual the default, and some discussion went into how to do the transition, but I don't believe that Andrei has ever liked the idea, and Walter never said that it was definitively happening, much as he seemed to have been convinced that it should happen. And no one has implemented a pull request for it, so nothing has happened. So AFAIK, it could go either way at this point. We should probably create a DIP for it and discuss it. I've been meaning to do that but have been quite busy lately and haven't gotten around to it.

- Jonathan M Davis

> On Tuesday, 10 September 2013 at 09:32:58 UTC, Jonathan M Davis wrote:
> AFAIK, no official decision has ever been made. It seemed like Walter was
> convinced that it was worth it to make non-virtual the default, and some
> discussion went into how to do the transition, but I don't believe that Andrei
> has ever liked the idea, and Walter never said that it was definitively
> happening, much as he seemed to have been convinced that it should happen. And
> no one has implemented a pull request for it, so nothing has happened. So
> AFAIK, it could go either way at this point. We should probably create a DIP
> for it and discuss it. I've been meaning to do that but have been quite busy
> lately and haven't gotten around to it.
>
> - Jonathan M Davis

Anyway, the introducing of the virtual keyword could be useful, even without the change. With that, we could interrupt final labes.

I use mostly:
----
final:
// final methods
----
but it would be nice if I don't have to put all virtual methods above the label. With virtual I could do it this way:
----
final:
// final methods
virtual:
// virtual methods
----

That's a huge comfort.

Another idea:
Currently the protection labels, like public, private etc. , can be restored. But other modifier, like const, nothrow, @safe or, in this case, final can't. I suggest to change this. We could use default for that purpose. Default could interrupt all modifier labels and would restore the default behaviour.

On 09/10/2013 02:28 AM, Andrei Alexandrescu wrote:
> ...
>
> After I've seen a pretty cool demo of clang-modernize
> (http://clang.llvm.org/extra/ModernizerUsage.html), I think the best way
> to attack this and similar problems is to add a class hierarchy
> analyzer: a command-line utility that is fed an entire project and adds
> as many 'final' as possible without changing semantics.
>
> Time has come to migrate such functionality to tools. We keep on telling
> that "nobody uses the tools" but it seems experience contradicts that
> belief.
>
>
> Andrei
>

This is of course a valid possibility, but if this kind of tooling is available, making the change becomes a rather trivial issue in the first place, since old code can just be fixed up automatically.

On 09/10/2013 01:46 PM, Timon Gehr wrote:
> On 09/10/2013 02:28 AM, Andrei Alexandrescu wrote:
>> ...
>>
>> After I've seen a pretty cool demo of clang-modernize
>> (http://clang.llvm.org/extra/ModernizerUsage.html), I think the best way
>> to attack this and similar problems is to add a class hierarchy
>> analyzer: a command-line utility that is fed an entire project and adds
>> as many 'final' as possible without changing semantics.
>>
>> Time has come to migrate such functionality to tools. We keep on telling
>> that "nobody uses the tools" but it seems experience contradicts that
>> belief.
>>
>>
>> Andrei
>>
>
> This is of course a valid possibility, but if this kind of tooling is
> available, making the change becomes a rather trivial issue in the first
> place, since old code can just be fixed up automatically.

(None of this is closely related to the OT though.)

On 10/09/13 11:32, Jonathan M Davis wrote:
> AFAIK, no official decision has ever been made. It seemed like Walter was
> convinced that it was worth it to make non-virtual the default, and some
> discussion went into how to do the transition, but I don't believe that Andrei
> has ever liked the idea, and Walter never said that it was definitively
> happening, much as he seemed to have been convinced that it should happen.

I seem to recall that the killer argument consisted of 2 parts:

   * Having final-by-default means having speed by default.  If people's
     default experience is slower than C++, they will not hang around to
     work out why or discover that speedups are possible.

   * With final by default, a missing "virtual" on a method can be corrected
     without breaking downstream code.  By contrast, with virtual by default,
     a missing "final" on a method (or whole class) can't be corrected without
     a risk of downstream breakage.

The second was the one that really sold it to me.

On Tuesday, September 10, 2013 18:53:32 Joseph Rushton Wakeling wrote:
> On 10/09/13 11:32, Jonathan M Davis wrote:
> > AFAIK, no official decision has ever been made. It seemed like Walter was convinced that it was worth it to make non-virtual the default, and some discussion went into how to do the transition, but I don't believe that Andrei has ever liked the idea, and Walter never said that it was definitively happening, much as he seemed to have been convinced that it should happen.
> I seem to recall that the killer argument consisted of 2 parts:
> 
> * Having final-by-default means having speed by default. If people's default experience is slower than C++, they will not hang around to work out why or discover that speedups are possible.
> 
> * With final by default, a missing "virtual" on a method can be
> corrected without breaking downstream code. By contrast, with virtual by
> default, a missing "final" on a method (or whole class) can't be corrected
> without a risk of downstream breakage.
> 
> The second was the one that really sold it to me.

What seemed to have convinced Walter was this interview

http://www.artima.com/intv/nonvirtualP.html

where the focus was on code maintainability and how C#'s approach to virtuality supported code versioning. However, most of the rest of the discussion and what most everyone else was looking for had to do with speed by default.

- Jonathan M Davis