• Namespace (5/5) Sep 09 2013 It's been a while since Manu convinced Walter and Andrei to
• H. S. Teoh (6/11) Sep 09 2013 This is going to break a lot of code. We'd need some kind of deprecation
• Namespace (4/15) Sep 09 2013 Even if it would break code, the introducing of the virtual
• Andrei Alexandrescu (10/19) Sep 09 2013 After I've seen a pretty cool demo of clang-modernize
• H. S. Teoh (8/27) Sep 09 2013 [...]
• Jacob Carlborg (4/12) Sep 10 2013 I completely agree. But then again, we need a D front end for this.
• Namespace (7/33) Sep 10 2013 Does it mean that we have to delay the change (virtual by default
• Simen Kjaeraas (5/26) Sep 10 2013 So the catastrophe that is virtual by default will not be changed?
• Jonathan M Davis (11/39) Sep 10 2013 AFAIK, no official decision has ever been made. It seemed like Walter wa...
• Namespace (17/37) Sep 10 2013 Anyway, the introducing of the virtual keyword could be useful,
• Namespace (6/6) Sep 10 2013 Another idea:
• Timon Gehr (4/14) Sep 10 2013 This is of course a valid possibility, but if this kind of tooling is
• Timon Gehr (2/21) Sep 10 2013 (None of this is closely related to the OT though.)
• Joseph Rushton Wakeling (10/15) Sep 10 2013 I seem to recall that the killer argument consisted of 2 parts:
• Andrej Mitrovic (4/5) Sep 09 2013 I'm not sure about that. It seems people who actually write
• Namespace (5/11) Sep 09 2013 So then: what's the matter? When does it starts? ;)
• H. S. Teoh (5/11) Sep 09 2013 Well, then I stand corrected. :)
• Andrej Mitrovic (2/3) Sep 09 2013 You may sit. You get a D.
• H. S. Teoh (5/9) Sep 09 2013 Just what I needed: another D in programming. :-P
• Jonathan M Davis (8/27) Sep 10 2013 What seemed to have convinced Walter was this interview
• Joseph Rushton Wakeling (5/14) Sep 10 2013 Yes, and the core of the case made in that interview was the

"Namespace" <rswhite4 googlemail.com> writes:

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.

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

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

-- 
Turning your clock 15 minutes ahead won't cure lateness---you're just making
time go faster!

"Namespace" <rswhite4 googlemail.com> writes:

On Monday, 9 September 2013 at 19:48:50 UTC, 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

Even if it would break code, the introducing of the virtual 
keyword could be done without. The change of virtual by default 
-> final by default could be done after the introducing.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

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

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

On Mon, Sep 09, 2013 at 05:28:24PM -0700, 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.


[...]
 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.

[...]

This would also be a good use case to motivate a reusable lexer/parser
(e.g., std.d.lexer that has been suggested for review).


T

-- 
Some days you win; most days you lose.

Jacob Carlborg <doob me.com> writes:

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

"Namespace" <rswhite4 googlemail.com> writes:

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?

"Simen Kjaeraas" <simen.kjaras gmail.com> writes:

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

Jonathan M Davis <jmdavisProg gmx.com> writes:

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

"Namespace" <rswhite4 googlemail.com> writes:

 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.

"Namespace" <rswhite4 googlemail.com> writes:

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.

Timon Gehr <timon.gehr gmx.ch> writes:

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.

Timon Gehr <timon.gehr gmx.ch> writes:

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

Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:

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.

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

On 9/9/13, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:
 And even then, it may anger a lot of existing users.

I'm not sure about that. It seems people who actually write
class-based code would prefer to have this (that's my limited analysis
of IRC comments :p).

"Namespace" <rswhite4 googlemail.com> writes:

On Monday, 9 September 2013 at 19:52:34 UTC, Andrej Mitrovic 
wrote:
 On 9/9/13, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:
 And even then, it may anger a lot of existing users.

 I'm not sure about that. It seems people who actually write
 class-based code would prefer to have this (that's my limited 
 analysis
 of IRC comments :p).

So then: what's the matter? When does it starts? ;)
It is much more important than those unnecessary DIP's like 47 / 
48.

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

On Mon, Sep 09, 2013 at 09:52:21PM +0200, Andrej Mitrovic wrote:
 On 9/9/13, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:
 And even then, it may anger a lot of existing users.

 
 I'm not sure about that. It seems people who actually write
 class-based code would prefer to have this (that's my limited analysis
 of IRC comments :p).

Well, then I stand corrected. :)


T

-- 
What do you get if you drop a piano down a mineshaft? A flat minor.

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

On 9/9/13, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:
 Well, then I stand corrected. :)

You may sit. You get a D.

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

On Mon, Sep 09, 2013 at 10:05:18PM +0200, Andrej Mitrovic wrote:
 On 9/9/13, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:
 Well, then I stand corrected. :)

 
 You may sit. You get a D.

Just what I needed: another D in programming. :-P


T

-- 
A computer doesn't mind if its programs are put to purposes that don't match
their names. -- D. Knuth

"Jonathan M Davis" <jmdavisProg gmx.com> writes:

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


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

"Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:

On Tuesday, 10 September 2013 at 18:42:16 UTC, Jonathan M Davis 
wrote:
 What seemed to have convinced Walter was this interview

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


 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.

Yes, and the core of the case made in that interview was the 
second of the arguments I cited, though in the interview it was 
made in more detail and more carefully argued.