www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Broken?

reply "Steve Teale" <steve.teale britseyeview.com> writes:
What D needs at this point is a dictator. There are about 30 
pages of discussion about Walter's std.array.front post, and 
Steve S's counter post.

It reminds me of the way it was maybe 4 years ago, when there was 
so much bickering that I just gave up for some time, and went 
away. Who is going to go through all that stuff, and winnow a 
compromise out of it. Everyone has a job, or some vital 
preoccupation with their own project.

The buck has to stop somewhere - is it Walter, or Andrei, or can 
any proposal or comment be stalled by sheer weight of contrary 
views?

This is probably a management issue, not a technical one. Trouble 
is there's no manager, and even if their was, he'd have no 
minions.

What to do?

Steve
Mar 11 2014
next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Tuesday, 11 March 2014 at 17:47:56 UTC, Steve Teale wrote:
 What D needs at this point is a dictator. There are about 30 
 pages of discussion about Walter's std.array.front post, and 
 Steve S's counter post.

 It reminds me of the way it was maybe 4 years ago, when there 
 was so much bickering that I just gave up for some time, and 
 went away. Who is going to go through all that stuff, and 
 winnow a compromise out of it. Everyone has a job, or some 
 vital preoccupation with their own project.

 The buck has to stop somewhere - is it Walter, or Andrei, or 
 can any proposal or comment be stalled by sheer weight of 
 contrary views?

 This is probably a management issue, not a technical one. 
 Trouble is there's no manager, and even if their was, he'd have 
 no minions.

 What to do?

 Steve
The buck does stop with Walter and Andrei. What you're seeing is community discussion, which informs their ultimate decisions. Are you saying that people shouldn't be discussing language decisions and that it should just be left to a couple of people? Also, of course Walter can decide not to do something due to community pressure. He has the ultimate say, it's his language, but that doesn't mean he shouldn't listen.
Mar 11 2014
next sibling parent "Steve Teale" <steve.teale britseyeview.com> writes:
On Tuesday, 11 March 2014 at 18:01:23 UTC, John Colvin wrote:
 The buck does stop with Walter and Andrei. What you're seeing 
 is community discussion, which informs their ultimate 
 decisions. Are you saying that people shouldn't be discussing 
 language decisions and that it should just be left to a couple 
 of people?

 Also, of course Walter can decide not to do something due to 
 community pressure. He has the ultimate say, it's his language, 
 but that doesn't mean he shouldn't listen.
I'm probably thinking more of some organization where if a discussion went off scale, something would happen, like a vote on the 3 main protagonists. If those 3 were not willing or able to get together and come up with a compromise, then the status quo should prevail until W/A decide otherwise. Lacking some compromise of that sort, D just becomes Balkanized. It did, and it recovered, but I think it sets things back. Steve
Mar 11 2014
prev sibling parent Russel Winder <russel winder.org.uk> writes:
On Tue, 2014-03-11 at 18:01 +0000, John Colvin wrote:
[=E2=80=A6]

 Also, of course Walter can decide not to do something due to=20
 community pressure. He has the ultimate say, it's his language,=20
 but that doesn't mean he shouldn't listen.
Python used to be Guido's language, but he and the community evolved out of that phase. It has not diminished Guido's status or standing. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Mar 12 2014
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 11 Mar 2014 13:47:55 -0400, Steve Teale  
<steve.teale britseyeview.com> wrote:

 What D needs at this point is a dictator. There are about 30 pages of  
 discussion about Walter's std.array.front post, and Steve S's counter  
 post.

 It reminds me of the way it was maybe 4 years ago, when there was so  
 much bickering that I just gave up for some time, and went away. Who is  
 going to go through all that stuff, and winnow a compromise out of it.  
 Everyone has a job, or some vital preoccupation with their own project.

 The buck has to stop somewhere - is it Walter, or Andrei, or can any  
 proposal or comment be stalled by sheer weight of contrary views?

 This is probably a management issue, not a technical one. Trouble is  
 there's no manager, and even if their was, he'd have no minions.

 What to do?
But it already is this way. What we have now are the gatekeepers of Walter and Andrei, and they (rightfully) hold a very high bar as to what should go into the language. They are the dictators, that we get to question and debate with. I don't consider it bickering at all. Debate, and especially heated debate, has always been a part of the forums. What else would you expect? Any time you have an open platform for discussion, things like this will show up. You can probably just ignore it, unless you care. In fact my newsreader has a feature to ignore entire threads. I ignore many of them, simply because I don't have the time in the day to debate everything. But things I care about, I want to make sure my point of view is being expressed, even if it's not me expressing it (in this case, nobody seemed to be presenting that view). This is not a democracy, and it's a good thing that it's not. But it absolutely must remain an open platform for people to voice opinions. Consider how long Walter resisted the call to make functions final by default, until he suddenly switched sides. I think of it like a dictatorship with 1000 advisors. And no death squads :) BTW, I don't expect a compromise, or really any movement, on the string issue. At least until someone has the wherewithal and motivation to actually try some things out with experimentation, and identify what the result might be. Until then, everything is theory. I was actually quite surprised Walter even considered fixing the problem to begin with. -Steve
Mar 11 2014
next sibling parent reply "Steve Teale" <steve.teale britseyeview.com> writes:
On Tuesday, 11 March 2014 at 18:14:52 UTC, Steven Schveighoffer 
wrote:
 On Tue, 11 Mar 2014 13:47:55 -0400, Steve Teale
Functions final by default? I read the list of changes for 2.065, and that one got by me completely. Aargh!
Mar 11 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Tuesday, 11 March 2014 at 18:29:35 UTC, Steve Teale wrote:
 On Tuesday, 11 March 2014 at 18:14:52 UTC, Steven Schveighoffer 
 wrote:
 On Tue, 11 Mar 2014 13:47:55 -0400, Steve Teale
Functions final by default? I read the list of changes for 2.065, and that one got by me completely. Aargh!
Not in 2.065 2.066 will introduce "virtual" keyword 2.067+ will change the defaults if it will still be considered good idea
Mar 11 2014
next sibling parent reply "Steve Teale" <steve.teale britseyeview.com> writes:
On Tuesday, 11 March 2014 at 18:35:57 UTC, Dicebot wrote:
 On Tuesday, 11 March 2014 at 18:29:35 UTC, Steve Teale wrote:
 On Tuesday, 11 March 2014 at 18:14:52 UTC, Steven 
 Schveighoffer wrote:
 On Tue, 11 Mar 2014 13:47:55 -0400, Steve Teale
Functions final by default? I read the list of changes for 2.065, and that one got by me completely. Aargh!
Not in 2.065 2.066 will introduce "virtual" keyword 2.067+ will change the defaults if it will still be considered good idea
Well if we're going there, we should go the whole hog and have final, direct, and virtual. It's a system programming language, so you should be able to walk down the street naked as long as you are prepared to put up with the consequences. Steve
Mar 11 2014
next sibling parent reply "Indica" <Indica Satvia.com> writes:
On Tuesday, 11 March 2014 at 18:42:23 UTC, Steve Teale wrote:
 On Tuesday, 11 March 2014 at 18:35:57 UTC, Dicebot wrote:
 On Tuesday, 11 March 2014 at 18:29:35 UTC, Steve Teale wrote:
 On Tuesday, 11 March 2014 at 18:14:52 UTC, Steven 
 Schveighoffer wrote:
 On Tue, 11 Mar 2014 13:47:55 -0400, Steve Teale
Functions final by default? I read the list of changes for 2.065, and that one got by me completely. Aargh!
Not in 2.065 2.066 will introduce "virtual" keyword 2.067+ will change the defaults if it will still be considered good idea
Well if we're going there, we should go the whole hog and have final, direct, and virtual. It's a system programming language, so you should be able to walk down the street naked as long as you are prepared to put up with the consequences. Steve
It sounds like what you are wanting is explicit project management. Possibly D could use a little work in that direction? Something like MS Project or a free alternative available to all(read only or git based with pulls). If it could be integrated with git then it would truly be powerful with pull requests, bounties, etc all showing up. Anyone could open it and see the current state, blocking issues, etc. Since Project can find the best "course of action" it would at least be efficient but might take quite a bit of work setting up. With such project management anyone could load up and see the current state, which I think would make D's direction quite a bit more concrete for people.
Mar 11 2014
next sibling parent reply "Indica" <Indica Satvia.com> writes:
I'd like to point out that Walter and Andrei can't do it all 
themselves. It takes a team and part of pulling it off is well 
defined goals and job descriptions with devoted people.
Mar 11 2014
parent reply "Steve Teale" <steve.teale britseyeview.com> writes:
On Tuesday, 11 March 2014 at 18:56:15 UTC, Indica wrote:
 I'd like to point out that Walter and Andrei can't do it all 
 themselves. It takes a team and part of pulling it off is well 
 defined goals and job descriptions with devoted people.
This is one of the motivations for my remark. They both have probably more tan enough to do without having to wade through the tremendous volume of responses. Steve
Mar 11 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/11/14, 11:36 PM, Steve Teale wrote:
 On Tuesday, 11 March 2014 at 18:56:15 UTC, Indica wrote:
 I'd like to point out that Walter and Andrei can't do it all
 themselves. It takes a team and part of pulling it off is well defined
 goals and job descriptions with devoted people.
This is one of the motivations for my remark. They both have probably more tan enough to do without having to wade through the tremendous volume of responses.
I could use more tan, can't wait for the summer :o). I'm glad you brought this up and that there was some good discussion following it. Walter is a very nice man. He dislikes saying "no" to people on account of them getting mad at him or the language. So he'd rather not answer. Lately we figured that's actually worse because it creates frustration (the perception is the request/effort is ignored, not acknowledged and declined). So we set to become more decisive about things. You may have noticed in recent history that we started more often to set the foot on the ground on one topic or another. We hope that that is healthy for the community. It also means for us all to accept the reality that in matters of judgment we can't always do what others believe is best, and on occasion (hopefully not too often!) even not what would objectively be the best decision. What I'd like us to achieve and convey in future debates is that whatever decision we make, we are making it in full understanding of all involved arguments. The "perpetual design" stage of D has ended. We've made our bed, it's time to lie in it. I foresee only one more area of possible breakage - thread support, and hopefully only code that was already broken should cease to compile. Andrei
Mar 12 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 The "perpetual design" stage of D has ended. We've made our 
 bed, it's time to lie in it.
If you don't change your bed once in a while, it will start to smell. A language dies if it doesn't keep a subgroup of people for its design, and when necessarily its redesign. Adapted from Simon Peyton Jones: ~We should avoid D success at all costs~
 I foresee only one more area of possible breakage - thread 
 support, and hopefully only code that was already broken should 
 cease to compile.
There is also to fix the small mess with tuples. I suggest to deprecate some usages of the comma. And there are few more small things to fix. Bye, bearophile
Mar 12 2014
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 3/12/2014 8:49 PM, bearophile wrote:
 Andrei Alexandrescu:

 The "perpetual design" stage of D has ended. We've made our bed, it's
 time to lie in it.
If you don't change your bed once in a while, it will start to smell. A language dies if it doesn't keep a subgroup of people for its design, and when necessarily its redesign.
Very true (see C++ and why D was needed ;) ), but of course the "perpetual design" stage of *D2* is over. I can certainly see an eventual D3 or D++ or E or whatever (with a smoother upgrade path than D1->D2), but not until D2 matures further. At some point we have to dial back on breaking changes and let things settle before the next round of "bedding changes".
Mar 12 2014
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 13 March 2014 at 00:37:42 UTC, Andrei Alexandrescu 
wrote:
 I could use more tan, can't wait for the summer :o).
Be careful. Sunglasses and sun cream indice 120 or you'll burn to ashes.
 Lately we figured that's actually worse because it creates 
 frustration (the perception is the request/effort is ignored, 
 not acknowledged and declined). So we set to become more 
 decisive about things. You may have noticed in recent history 
 that we started more often to set the foot on the ground on one 
 topic or another.
Yes, that is a good change. More frustrating on the short run, but less on exhausting on the long run.
Mar 12 2014
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Mar 13, 2014 at 05:10:42AM +0000, deadalnix wrote:
 On Thursday, 13 March 2014 at 00:37:42 UTC, Andrei Alexandrescu
[...]
Lately we figured that's actually worse because it creates
frustration (the perception is the request/effort is ignored, not
acknowledged and declined). So we set to become more decisive
about things. You may have noticed in recent history that we
started more often to set the foot on the ground on one topic or
another.
Yes, that is a good change. More frustrating on the short run, but less on exhausting on the long run.
Yes, I also applaud this attitude. Taking decisive action not only saves time / energy arguing back and forth, it also boosts morale and gives a sense of direction. Keeping silent about things hurts morale because it can be (wrongly) perceived as ignoring the issue, being indecisive, or deliberately stonewalling. Any feedback is better than silence, even if it's a "no". T -- Freedom of speech: the whole world has no right *not* to hear my spouting off!
Mar 12 2014
prev sibling next sibling parent "Joseph Cassman" <jc7919 outlook.com> writes:
On Thursday, 13 March 2014 at 00:37:42 UTC, Andrei Alexandrescu 
wrote:
 On 3/11/14, 11:36 PM, Steve Teale wrote:
 On Tuesday, 11 March 2014 at 18:56:15 UTC, Indica wrote:
 I'd like to point out that Walter and Andrei can't do it all
 themselves. It takes a team and part of pulling it off is 
 well defined
 goals and job descriptions with devoted people.
This is one of the motivations for my remark. They both have probably more tan enough to do without having to wade through the tremendous volume of responses.
I could use more tan, can't wait for the summer :o). I'm glad you brought this up and that there was some good discussion following it. Walter is a very nice man. He dislikes saying "no" to people on account of them getting mad at him or the language. So he'd rather not answer. Lately we figured that's actually worse because it creates frustration (the perception is the request/effort is ignored, not acknowledged and declined). So we set to become more decisive about things. You may have noticed in recent history that we started more often to set the foot on the ground on one topic or another. We hope that that is healthy for the community. It also means for us all to accept the reality that in matters of judgment we can't always do what others believe is best, and on occasion (hopefully not too often!) even not what would objectively be the best decision. What I'd like us to achieve and convey in future debates is that whatever decision we make, we are making it in full understanding of all involved arguments. The "perpetual design" stage of D has ended. We've made our bed, it's time to lie in it. I foresee only one more area of possible breakage - thread support, and hopefully only code that was already broken should cease to compile. Andrei
Appreciate the change. The increased clarity is helpful. Thanks. Joseph
Mar 12 2014
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, March 12, 2014 17:37:37 Andrei Alexandrescu wrote:
 The "perpetual design" stage of D has ended. We've made our bed, it's
 time to lie in it. I foresee only one more area of possible breakage -
 thread support, and hopefully only code that was already broken should
 cease to compile.
Another major area which we've discussed changing (and agreed on - we just haven't actually managed to implement the changes) is removing toString, toHash, opEquals, and opCmp from Object to fix the const problem. That's likely to introduce breaking changes - well worth it IMHO, and hopefully it can be done with minimal disruption - but it's a pretty big change nonetheless - Jonathan M Davis
Mar 13 2014
prev sibling parent "Steve Teale" <steve.teale britseyeview.com> writes:
On Thursday, 13 March 2014 at 00:37:42 UTC, Andrei Alexandrescu 
wrote:
 On 3/11/14, 11:36 PM, Steve Teale wrote:
 On Tuesday, 11 March 2014 at 18:56:15 UTC, Indica wrote:
 I'd like to point out that Walter and Andrei can't do it all
 themselves. It takes a team and part of pulling it off is 
 well defined
 goals and job descriptions with devoted people.
This is one of the motivations for my remark. They both have probably more than enough to do without having to wade through the tremendous volume of responses.
Walter is a very nice man. He dislikes saying "no" to people on account of them getting mad at him or the language. So he'd rather not answer.
Walter is a complex and proud man, like most of us. I love him dearly - he (along with John Haggins - who you maybe never heard of), changed my life. I'm getting old now, so the old adage "if it ain't broken, don't mend it" becomes very appealing. Except, of course for 'direct' ;=) I think, looking at the current arguments, that C++ may have got it right there. And, since it wasn't there before, can it break anything? Steve Steve
Mar 13 2014
prev sibling parent "Dicebot" <public dicebot.lv> writes:
On Tuesday, 11 March 2014 at 18:54:37 UTC, Indica wrote:
 It sounds like what you are wanting is explicit project 
 management.

 Possibly D could use a little work in that direction? Something 
 like MS Project or a free alternative available to all(read 
 only or git based with pulls).
There is no point in project management with no team to manage. As far as I understand there is no structured collaboration inside D core team and no strict responsibilities, just group of people working on what they consider important and sometimes communicating to figure out corner cases. At least this is what I see judging by GitHub / NG activity.
Mar 11 2014
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 3/11/2014 2:42 PM, Steve Teale wrote:
 Well if we're going there, we should go the whole hog and have final,
 direct, and virtual.
Pardon my ignorance: What's 'direct'?
 It's a system programming language, so you should
 be able to walk down the street naked as long as you are prepared to put
 up with the consequences.
There has been much debate in the programming community over what exactly "system programming language" means. I think you, sir, have found the winner! Gets my vote, anyway! :)
Mar 11 2014
parent "Steve Teale" <steve.teale britseyeview.com> writes:
On Tuesday, 11 March 2014 at 22:24:15 UTC, Nick Sabalausky wrote:
 On 3/11/2014 2:42 PM, Steve Teale wrote:
 Well if we're going there, we should go the whole hog and have 
 final,
 direct, and virtual.
Pardon my ignorance: What's 'direct'?
 It's a system programming language, so you should
 be able to walk down the street naked as long as you are 
 prepared to put
 up with the consequences.
There has been much debate in the programming community over what exactly "system programming language" means. I think you, sir, have found the winner! Gets my vote, anyway! :)
What I meant by final is simply the third leg of a tuffet. As I understand it, final means called directly, and you can't override, virtual means called through the vtable and you can override, direct means called directly, but you can override (hide) in a derived class, like if you define a method with the same signature in a derived class in C++ when the base class method is not marked as virtual. I tried that with G++ the other day, and it still seems to compile. There may be other possibilities, I have not attempted to draw the matrix table. Steve
Mar 11 2014
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 11 March 2014 at 18:35:57 UTC, Dicebot wrote:
 On Tuesday, 11 March 2014 at 18:29:35 UTC, Steve Teale wrote:
 On Tuesday, 11 March 2014 at 18:14:52 UTC, Steven 
 Schveighoffer wrote:
 On Tue, 11 Mar 2014 13:47:55 -0400, Steve Teale
Functions final by default? I read the list of changes for 2.065, and that one got by me completely. Aargh!
Not in 2.065 2.066 will introduce "virtual" keyword 2.067+ will change the defaults if it will still be considered good idea
What ???
Mar 11 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Dicebot:

 Not in 2.065
 2.066  will introduce "virtual" keyword
 2.067+ will change the defaults if it will still be considered 
 good idea
What's the point of having "virtual" if the default doesn't change? Bye, bearophile
Mar 11 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Tuesday, 11 March 2014 at 21:24:22 UTC, bearophile wrote:
 Dicebot:

 Not in 2.065
 2.066  will introduce "virtual" keyword
 2.067+ will change the defaults if it will still be considered 
 good idea
What's the point of having "virtual" if the default doesn't change? Bye, bearophile
frequently mentioned example: class Something { final: // want all to be final by default // ... virtual void foo() {} // but this one function } I think just keeping "virtual" but not changing defaults is a good practical compromise.
Mar 11 2014
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 11 March 2014 at 21:29:00 UTC, Dicebot wrote:
     final: // want all to be final by default

     // ...

     virtual void foo() {} // but this one function
Doesn't this make room for undetected bugs? Generally the syntax should have enough redundancy to prevent a single typo (missing ":") from completely changing the semantics. Ola.
Mar 11 2014
parent "Dicebot" <public dicebot.lv> writes:
On Tuesday, 11 March 2014 at 21:35:12 UTC, Ola Fosheim Grøstad 
wrote:
 On Tuesday, 11 March 2014 at 21:29:00 UTC, Dicebot wrote:
    final: // want all to be final by default

    // ...

    virtual void foo() {} // but this one function
Doesn't this make room for undetected bugs? Generally the syntax should have enough redundancy to prevent a single typo (missing ":") from completely changing the semantics. Ola.
Mostly depends on the way you format the code. It is perfectly consistent with existing safe / system interaction though and allows to define defaults in user code without changing anything in the language ;)
Mar 11 2014
prev sibling parent reply Manu <turkeyman gmail.com> writes:
On 12 March 2014 07:28, Dicebot <public dicebot.lv> wrote:

 On Tuesday, 11 March 2014 at 21:24:22 UTC, bearophile wrote:

 Dicebot:

  Not in 2.065
 2.066  will introduce "virtual" keyword
 2.067+ will change the defaults if it will still be considered good idea
What's the point of having "virtual" if the default doesn't change? Bye, bearophile
frequently mentioned example: class Something { final: // want all to be final by default // ... virtual void foo() {} // but this one function } I think just keeping "virtual" but not changing defaults is a good practical compromise.
I'm really trying to keep my lid on here... I'll just remind that in regard to this particular point which sounds reasonable, it's easy to forgot that *all library code where the author didn't care* is now unusable by anybody who does. The converse would not be true if the situation was reversed. virtual-by-default is incompatible with optimisation, and it's reliable to assume that anybody who doesn't explicitly care about this will stick with the default, which means many potentially useful libraries may be eliminated for use by many customers. Also, as discussed at length, revoking virtual from a function is a breaking change, adding virtual is not. Which means that, instead of making a controlled breaking change with a clear migration path here and now, we are committing every single instance of any user's intent to 'optimise' their libraries (by finalising unnecessarily virtuals) to breaking changes in their ABI - which *will* occur, since virtual is the default. According to semantic versioning, this requires bumping the major version number... that's horrible! What's better; implementing a controlled deprecation path now, or leaving it up to any project that ever uses the 'class' keyword to eventually confront breaking changes in their API when they encounter a performance oriented customer?
Mar 11 2014
next sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Wednesday, 12 March 2014 at 03:05:00 UTC, Manu wrote:
 I'm really trying to keep my lid on here...

 I'll just remind that in regard to this particular point which 
 sounds
 reasonable, it's easy to forgot that *all library code where 
 the author
 didn't care* is now unusable by anybody who does. The converse 
 would not be
 true if the situation was reversed.

 virtual-by-default is incompatible with optimisation, and it's 
 reliable to
 assume that anybody who doesn't explicitly care about this will 
 stick with
 the default, which means many potentially useful libraries may 
 be
 eliminated for use by many customers.
 Also, as discussed at length, revoking virtual from a function 
 is a
 breaking change, adding virtual is not. Which means that, 
 instead of making
 a controlled breaking change with a clear migration path here 
 and now, we
 are committing every single instance of any user's intent to 
 'optimise'
 their libraries (by finalising unnecessarily virtuals) to 
 breaking changes
 in their ABI - which *will* occur, since virtual is the default.
 According to semantic versioning, this requires bumping the 
 major version
 number... that's horrible!

 What's better; implementing a controlled deprecation path now, 
 or leaving
 it up to any project that ever uses the 'class' keyword to 
 eventually
 confront breaking changes in their API when they encounter a 
 performance
 oriented customer?
Case in point: https://github.com/D-Programming-Language/phobos/pull/1771 "mark std.zip classes as final" Long story short: MartinNowak decided to make the Zip classes final, since it made no sense to have any of the functions virtual, or to have anybody derive from them anyways. https://github.com/D-Programming-Language/phobos/pull/1771#issuecomment-36524041 Comment from Dav1dde: "Just to let you know, it broke my code"
Mar 12 2014
parent reply Manu <turkeyman gmail.com> writes:
On 12 March 2014 20:40, monarch_dodra <monarchdodra gmail.com> wrote:

 On Wednesday, 12 March 2014 at 03:05:00 UTC, Manu wrote:

 I'm really trying to keep my lid on here...

 I'll just remind that in regard to this particular point which sounds
 reasonable, it's easy to forgot that *all library code where the author
 didn't care* is now unusable by anybody who does. The converse would not
 be
 true if the situation was reversed.

 virtual-by-default is incompatible with optimisation, and it's reliable to
 assume that anybody who doesn't explicitly care about this will stick with
 the default, which means many potentially useful libraries may be
 eliminated for use by many customers.
 Also, as discussed at length, revoking virtual from a function is a
 breaking change, adding virtual is not. Which means that, instead of
 making
 a controlled breaking change with a clear migration path here and now, we
 are committing every single instance of any user's intent to 'optimise'
 their libraries (by finalising unnecessarily virtuals) to breaking changes
 in their ABI - which *will* occur, since virtual is the default.
 According to semantic versioning, this requires bumping the major version
 number... that's horrible!

 What's better; implementing a controlled deprecation path now, or leaving
 it up to any project that ever uses the 'class' keyword to eventually
 confront breaking changes in their API when they encounter a performance
 oriented customer?
Case in point: https://github.com/D-Programming-Language/phobos/pull/1771 "mark std.zip classes as final" Long story short: MartinNowak decided to make the Zip classes final, since it made no sense to have any of the functions virtual, or to have anybody derive from them anyways. https://github.com/D-Programming-Language/phobos/pull/1771#issuecomment- 36524041 Comment from Dav1dde: "Just to let you know, it broke my code"
Thank you. There you go, it's not even hypothetical.
Mar 12 2014
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 12 March 2014 at 11:40:39 UTC, Manu wrote:
 On 12 March 2014 20:40, monarch_dodra <monarchdodra gmail.com> 
 wrote:

 On Wednesday, 12 March 2014 at 03:05:00 UTC, Manu wrote:

 I'm really trying to keep my lid on here...

 I'll just remind that in regard to this particular point 
 which sounds
 reasonable, it's easy to forgot that *all library code where 
 the author
 didn't care* is now unusable by anybody who does. The 
 converse would not
 be
 true if the situation was reversed.

 virtual-by-default is incompatible with optimisation, and 
 it's reliable to
 assume that anybody who doesn't explicitly care about this 
 will stick with
 the default, which means many potentially useful libraries 
 may be
 eliminated for use by many customers.
 Also, as discussed at length, revoking virtual from a 
 function is a
 breaking change, adding virtual is not. Which means that, 
 instead of
 making
 a controlled breaking change with a clear migration path here 
 and now, we
 are committing every single instance of any user's intent to 
 'optimise'
 their libraries (by finalising unnecessarily virtuals) to 
 breaking changes
 in their ABI - which *will* occur, since virtual is the 
 default.
 According to semantic versioning, this requires bumping the 
 major version
 number... that's horrible!

 What's better; implementing a controlled deprecation path 
 now, or leaving
 it up to any project that ever uses the 'class' keyword to 
 eventually
 confront breaking changes in their API when they encounter a 
 performance
 oriented customer?
Case in point: https://github.com/D-Programming-Language/phobos/pull/1771 "mark std.zip classes as final" Long story short: MartinNowak decided to make the Zip classes final, since it made no sense to have any of the functions virtual, or to have anybody derive from them anyways. https://github.com/D-Programming-Language/phobos/pull/1771#issuecomment- 36524041 Comment from Dav1dde: "Just to let you know, it broke my code"
Thank you. There you go, it's not even hypothetical.
It can also happen the other way if I mark a method virtual that used to be final, which was overloaded in a subclass, right? -- Paulo
Mar 12 2014
parent "Kapps" <opantm2+spam gmail.com> writes:
On Wednesday, 12 March 2014 at 11:59:45 UTC, Paulo Pinto wrote:
 On Wednesday, 12 March 2014 at 11:40:39 UTC, Manu wrote:

 It can also happen the other way if I mark a method virtual 
 that used to be final, which was overloaded in a subclass, 
 right?

 --
 Paulo
as well) is that shadowing a virtual method is a warning. If Bar derives from Foo and implements foobar(int), then at some point Foo decides to add foobar(int), Bar's foobar(int) will not be virtual but a warning will be given that it shadows Foo.foobar(int). You can then either mark it override, or you can mark it new to indicate that you are aware it shadows the method and don't want to overload it. So going from final to virtual is not a breaking change (but you will receive a warning until you acknowledge that you're shadowing the method), but going from virtual to final is a breaking change.
Mar 13 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/12/14, 4:40 AM, Manu wrote:
 Thank you.
 There you go, it's not even hypothetical.
I think the example given works against your argument. Andrei
Mar 12 2014
next sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Wednesday, 12 March 2014 at 16:46:26 UTC, Andrei Alexandrescu 
wrote:
 On 3/12/14, 4:40 AM, Manu wrote:
 Thank you.
 There you go, it's not even hypothetical.
I think the example given works against your argument. Andrei
How so? The example was his argument verbatim.
Mar 12 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/12/14, 10:05 AM, monarch_dodra wrote:
 On Wednesday, 12 March 2014 at 16:46:26 UTC, Andrei Alexandrescu wrote:
 On 3/12/14, 4:40 AM, Manu wrote:
 Thank you.
 There you go, it's not even hypothetical.
I think the example given works against your argument. Andrei
How so? The example was his argument verbatim.
His argument assumed at core that the library designer knows better than the library user what the customization points are, and that most functions are virtual by mistake. Andrei
Mar 12 2014
next sibling parent reply "Sean Kelly" <sean invisibleduck.org> writes:
On Wednesday, 12 March 2014 at 17:08:59 UTC, Andrei Alexandrescu
wrote:
 On 3/12/14, 10:05 AM, monarch_dodra wrote:
 On Wednesday, 12 March 2014 at 16:46:26 UTC, Andrei 
 Alexandrescu wrote:
 On 3/12/14, 4:40 AM, Manu wrote:
 Thank you.
 There you go, it's not even hypothetical.
I think the example given works against your argument. Andrei
How so? The example was his argument verbatim.
His argument assumed at core that the library designer knows better than the library user what the customization points are, and that most functions are virtual by mistake.
And this argument is absolutely correct, in my experience. By making virtuality an explicit choice, the library designer is specifying that a given function is a part of the published interface for a class and overriding it has some explicit purpose that will be maintained over time. In a "virtual by default" world, there is no explicit contract regarding the virtuality of functions, and so the library writer may not feel any obligation to retain those functions at all, their signatures, or their application to the operation of the class. Unless a particular function is documented as overridable, you can't assume that the library writer didn't simply forget to mark it final. Doing otherwise puts the library writer in an awkward position by imposing an obligation to preserve behavior that was never intended to be public in the first place. The example provided demonstrated this exact problem.
Mar 12 2014
next sibling parent "Sean Kelly" <sean invisibleduck.org> writes:
And for the record, I'm absolutely pedantic about adding "final"
qualifiers to functions that aren't intended to be overridable,
and yet it recently came to light that the methods a class in
Druntime that I created (Condition) are not labeled final.  I
can't imagine any reason why I'd have made that decision
explicitly, since there's no real function to having them be
overridable.  It was obviously a mistake on my part, and yet
there are two instances where Condition has been subclassed and
these methods overridden (once by me, to be honest), to
questionable ends.  And so at this point I can't add the "final"
qualifier without breaking user code, even though it was always
meant to be there.

In short, I don't think that saying this is often overlooked is
even necessarily an assertion that library writers are sloppy or
don't care about performance.  It being the default behavior and
having no detectable issues at design time means that these
problems will slip in from time to time.  It's hard to grep for
the lack of a keyword.
Mar 12 2014
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-03-12 20:51, Sean Kelly wrote:

 And this argument is absolutely correct, in my experience.  By
 making virtuality an explicit choice, the library designer is
 specifying that a given function is a part of the published
 interface for a class and overriding it has some explicit purpose
 that will be maintained over time.
There's a book, Effective Java, that recommends all methods should be marked as final unless explicitly intended to be overridden. The argument is that a class needs to be explicitly designed for subclassing. -- /Jacob Carlborg
Mar 12 2014
prev sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
12-Mar-2014 23:51, Sean Kelly пишет:
 On Wednesday, 12 March 2014 at 17:08:59 UTC, Andrei Alexandrescu
 wrote:
 On 3/12/14, 10:05 AM, monarch_dodra wrote:
 On Wednesday, 12 March 2014 at 16:46:26 UTC, Andrei Alexandrescu wrote:
 On 3/12/14, 4:40 AM, Manu wrote:
 Thank you.
 There you go, it's not even hypothetical.
I think the example given works against your argument. Andrei
How so? The example was his argument verbatim.
His argument assumed at core that the library designer knows better than the library user what the customization points are, and that most functions are virtual by mistake.
And this argument is absolutely correct, in my experience. By making virtuality an explicit choice, the library designer is specifying that a given function is a part of the published interface for a class and overriding it has some explicit purpose that will be maintained over time.
Seconded. -- Dmitry Olshansky
Mar 12 2014
prev sibling parent reply "Kapps" <opantm2+spam gmail.com> writes:
On Wednesday, 12 March 2014 at 17:08:59 UTC, Andrei Alexandrescu 
wrote:
 On 3/12/14, 10:05 AM, monarch_dodra wrote:
 On Wednesday, 12 March 2014 at 16:46:26 UTC, Andrei 
 Alexandrescu wrote:
 On 3/12/14, 4:40 AM, Manu wrote:
 Thank you.
 There you go, it's not even hypothetical.
I think the example given works against your argument. Andrei
How so? The example was his argument verbatim.
His argument assumed at core that the library designer knows better than the library user what the customization points are, and that most functions are virtual by mistake. Andrei
There were countless arguments to demonstrate that this *is* the case. If the developer had not considered whether the function is safe to be virtual, it's not safe. A change request could be made for exposing a customization point, but it is something that needs to be done explicitly by the library designer, not just override and hope that it works out. And of course, once you do expose it you're stuck with it and the design that supports it unless you want to break user code. It would be interesting to scrape Github projects using Java percentage of virtual functions is between each of them, as well as see how many easily statically noticed probable bugs there are (i.e., virtual property operating on a backing field which is then accessed directly by a different method in the base class) in each of them.
Mar 13 2014
parent "w0rp" <devw0rp gmail.com> writes:
I used to believe that virtual was a better default, but these 
days I think the opposite. My reasoning is that inheritance is a 
very poor tool for code reuse. The way I see it now, inheritance 
is a tool for modelling "is a" relationships and variations on 
objects, but it's bad to use it in an API as a "to implement your 
business logic inherit here" thing.

You get much better code reuse out of functions, especially with 
generic programming. (D being the number one generic language 
with its templates and CTFE.) The more loosely coupled the data 
becomes from the business logic, the higher application quality 
appears to be and the more breakage decreases. Presenting an 
interface for a library whereby the types can automatically be 
overridden is a good way to lead people into writing code that's 
going to break later and may burden the library's implementer 
with supporting something he didn't know he'd need to support. 
(e.g. in Nowak's ZIP library.)
Mar 13 2014
prev sibling parent Manu <turkeyman gmail.com> writes:
On 13 March 2014 02:46, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org>wrote:

 On 3/12/14, 4:40 AM, Manu wrote:

 Thank you.
 There you go, it's not even hypothetical.
I think the example given works against your argument.
How so? Virtual was removed, code broke. This is the default state of D. The other direction has no such problem.
Mar 12 2014
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2014-03-12 03:04:38 +0000, Manu <turkeyman gmail.com> said:

 virtual-by-default is incompatible with optimisation, and it's reliable to
 assume that anybody who doesn't explicitly care about this will stick with
 the default, which means many potentially useful libraries may be
 eliminated for use by many customers.
I'll add another argument to the mix. Currently, you can't have private/package functions that are virtual, contrary to what TDPL says. To make things coherent we could change private function so they become virtual by default. You might be able to see the problem with this option: making private function virtual by default is likely to add many performance regressions in existing code, silently. Or we could implement final by default. This option would instead force people to add 'virtual' here and there, but otherwise existing code is likely to run faster after that. We could always keep things as they currently are: private/package is not virtual, everything else is virtual unless marked final. Honestly I'd like to se that go. The protection attribute should have nothing to do with whether a function is virtual or not. -- Michel Fortin michel.fortin michelf.ca http://michelf.ca
Mar 12 2014
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 12 Mar 2014 08:32:14 -0400, Michel Fortin  
<michel.fortin michelf.ca> wrote:

 On 2014-03-12 03:04:38 +0000, Manu <turkeyman gmail.com> said:

 virtual-by-default is incompatible with optimisation, and it's reliable  
 to
 assume that anybody who doesn't explicitly care about this will stick  
 with
 the default, which means many potentially useful libraries may be
 eliminated for use by many customers.
I'll add another argument to the mix. Currently, you can't have private/package functions that are virtual, contrary to what TDPL says. To make things coherent we could change private function so they become virtual by default. You might be able to see the problem with this option: making private function virtual by default is likely to add many performance regressions in existing code, silently.
Private virtual functions make 0 sense. A private function cannot be accessed by a derived class. Who gets to access a overriden virtual function? The base class only? If I'm writing a function, I certainly should be able to access it, no? Even if you want to restrict my access, you cannot, I'm in control of that code! Package, I'm less concerned about. You can make that virtual, I don't ever use package functions. -Steve
Mar 12 2014
next sibling parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2014-03-12 12:48:59 +0000, "Steven Schveighoffer" 
<schveiguy yahoo.com> said:

 On Wed, 12 Mar 2014 08:32:14 -0400, Michel Fortin  
 <michel.fortin michelf.ca> wrote:
 
 I'll add another argument to the mix.
 
 Currently, you can't have private/package functions that are virtual,  
 contrary to what TDPL says.
 
 To make things coherent we could change private function so they become 
  virtual by default. You might be able to see the problem with this  
 option: making private function virtual by default is likely to add 
 many  performance regressions in existing code, silently.
Private virtual functions make 0 sense. A private function cannot be accessed by a derived class. Who gets to access a overriden virtual function? The base class only? If I'm writing a function, I certainly should be able to access it, no? Even if you want to restrict my access, you cannot, I'm in control of that code!
You're mixing C++ private with D private. Private just means the symbol is only accessible within the same module. You can have a whole class hierarchy in a module if you want, and thus could override private functions assuming they could be virtual. -- Michel Fortin michel.fortin michelf.ca http://michelf.ca
Mar 12 2014
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 12 Mar 2014 09:15:14 -0400, Michel Fortin  
<michel.fortin michelf.ca> wrote:

 On 2014-03-12 12:48:59 +0000, "Steven Schveighoffer"  
 <schveiguy yahoo.com> said:

 On Wed, 12 Mar 2014 08:32:14 -0400, Michel Fortin   
 <michel.fortin michelf.ca> wrote:

 I'll add another argument to the mix.
  Currently, you can't have private/package functions that are  
 virtual,  contrary to what TDPL says.
  To make things coherent we could change private function so they  
 become  virtual by default. You might be able to see the problem with  
 this  option: making private function virtual by default is likely to  
 add many  performance regressions in existing code, silently.
Private virtual functions make 0 sense. A private function cannot be accessed by a derived class. Who gets to access a overriden virtual function? The base class only? If I'm writing a function, I certainly should be able to access it, no? Even if you want to restrict my access, you cannot, I'm in control of that code!
You're mixing C++ private with D private. Private just means the symbol is only accessible within the same module. You can have a whole class hierarchy in a module if you want, and thus could override private functions assuming they could be virtual.
OK, I can see that being useful. You are right, I was thinking C++ private. So essentially, a virtual private function can only be overridden in classes defined in the same module. What happens when you do it in a separate module, an error? What if you want to define that function name, but it's taken by the base class, what happens? -Steve
Mar 12 2014
next sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Wednesday, 12 March 2014 at 13:22:34 UTC, Steven Schveighoffer 
wrote:
 OK, I can see that being useful. You are right, I was thinking 
 C++ private.

 -Steve
Even in C++, private virtual a key part of the "non-virtual interface" thing. EG: You define your base class as having only non-virtual public functions, and private virtual function. They are private, so the derived classes can't *call* them, but they can still override them. The idea is that the base class holds any "non-modifyable" behavior, and the virtual functions are only "customizeable sub-part behavior". For example, C++ streams work that way: All the public functions are non-virtual. To create your own streams, you are supposed to only override a set of low level functions, and then the base class takes care of calling them correctly. In any case, that's how "private virtual" makes sense in C++. I'm less fluent with how it works D classes, but last time I read TDPL, I seem to remember it was built-in in some way.
Mar 12 2014
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 12 Mar 2014 09:45:22 -0400, monarch_dodra <monarchdodra gmail.com>  
wrote:

 On Wednesday, 12 March 2014 at 13:22:34 UTC, Steven Schveighoffer wrote:
 OK, I can see that being useful. You are right, I was thinking C++  
 private.

 -Steve
Even in C++, private virtual a key part of the "non-virtual interface" thing. EG: You define your base class as having only non-virtual public functions, and private virtual function. They are private, so the derived classes can't *call* them, but they can still override them.
Nonsense. If I'm writing a function, I can call it. There is no way to prevent it. e.g.: class X { virtual void _foo() {/* default impl */} public: void foo() {_foo();} } class Y : public X { virtual void _foo() {_foo2();} void _foo2() { /* do whatever I want here */} } OK, so your idea is that I can't call my copy of _foo, which if that's how it works, is dumb in my opinion. But if that's the case, I'm in control of its implementation, I can just forward to another function that I can call.
 The idea is that the base class holds any "non-modifyable" behavior, and  
 the virtual functions are only "customizeable sub-part behavior".

 For example, C++ streams work that way: All the public functions are  
 non-virtual. To create your own streams, you are supposed to only  
 override a set of low level functions, and then the base class takes  
 care of calling them correctly.
The idea is fine, but protected serves this purpose just as well. -Steve
Mar 12 2014
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 3/12/14, Steven Schveighoffer <schveiguy yahoo.com> wrote:
 The idea is fine, but protected serves this purpose just as well.
Protected still allows subclasses to *call* the methods. The idea is that the base class provides a public API which implements the calling, because only it knows in which order some private functions should be called.
Mar 12 2014
prev sibling next sibling parent "Szymon Gatner" <noemail gmail.com> writes:
On Wednesday, 12 March 2014 at 13:53:28 UTC, Steven Schveighoffer 
wrote:
 On Wed, 12 Mar 2014 09:45:22 -0400, monarch_dodra 
 <monarchdodra gmail.com> wrote:

 On Wednesday, 12 March 2014 at 13:22:34 UTC, Steven 
 Schveighoffer wrote:
 OK, I can see that being useful. You are right, I was 
 thinking C++ private.

 -Steve
Even in C++, private virtual a key part of the "non-virtual interface" thing. EG: You define your base class as having only non-virtual public functions, and private virtual function. They are private, so the derived classes can't *call* them, but they can still override them.
Nonsense. If I'm writing a function, I can call it. There is no way to prevent it. e.g.:
The point is that you can't call parent's virtual (often abstract) method. Of course you can call method you define but that is not the point of NVI.
Mar 12 2014
prev sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Wednesday, 12 March 2014 at 13:53:28 UTC, Steven Schveighoffer 
wrote:
 Nonsense. If I'm writing a function, I can call it. There is no 
 way to prevent it.
Yes, you are right. You can always call the function directly if you so wish, since you *are* defining it. But the idea is that it should just be a "piece of implementation" that should only be used in a controlled environment, as defined by the base class.
 OK, so your idea is that I can't call my copy of _foo, which if 
 that's how it works, is dumb in my opinion. But if that's the 
 case, I'm in control of its implementation, I can just forward 
 to another function that I can call.
Absolutely. And in NVI, arguably, that's a good idea. By doing this, you are basically creating a second level NVI for a potential third level implementation. *if* your derived class made a direct call to the virtual (protected) function, then you'd be voiding the base classes' guarantees for any other derived class.
 The idea is fine, but protected serves this purpose just as 
 well.
The basic idea of NVI is encapsulation of behavior. The derived class, while they are the ones defining the implementation, are considered no different from any other client, and are not given call rights. If you make the functions protected, then you are granting them access to implementation internals, which means weaker encapsulation. For a 1-level hierarchy, it doesn't make much difference, but the deeper you go, and the less robust the design gets.
Mar 12 2014
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 03/12/2014 02:22 PM, Steven Schveighoffer wrote:

 OK, I can see that being useful. You are right, I was thinking C++ private.

 So essentially, a virtual private function can only be overridden in
 classes defined in the same module. What happens when you do it in a
 separate module, an error?
In a different module, attempting an override should behave as if the base class didn't define the member function.
 What if you want to define that function
 name, but it's taken by the base class, what happens?
It's not taken. There are corner cases, when eg. the module with the private member function imports a module with a public member function hiding the private one (i.e., circular imports) and then uses this newly defined member function, possibly expecting to call its own private member. Then it should maybe be an error. :o) Anyway, I think the main issue with virtual private and virtual package is that they'd influence the class ABI.
Mar 12 2014
prev sibling parent "Steve Teale" <steve.teale britseyeview.com> writes:
On Wednesday, 12 March 2014 at 13:22:34 UTC, Steven Schveighoffer 
wrote:
 when you do it in a separate module, an error? What if you want 
 to define that function name, but it's taken by the base class, 
 what happens?

 -Steve
That's when you need 'direct' ;=) Steve
Mar 12 2014
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 3/12/14, Steven Schveighoffer <schveiguy yahoo.com> wrote:
 Private virtual functions make 0 sense. A private function cannot be
 accessed by a derived class.
It can if it's in the same module. You may want to have the benefit of virtual functions, but also the benefit of those methods being accessible in some internal API, but not to the user. If you make them protected, they're accessible by user-derived classes. You could make them package, but currently package is forced non-virtual as well.
 Package, I'm less concerned about. You can make that virtual, I don't ever
 use package functions.
There is definitely a need for this. DFeed is full of these style of comments: /+ package +/ /+ protected +/ override int _rtype() // package It's obviously supposed to be hidden from the user, but it can't be. So underscores are prepended instead.
Mar 12 2014
prev sibling parent "Szymon Gatner" <noemail gmail.com> writes:
On Wednesday, 12 March 2014 at 12:48:58 UTC, Steven Schveighoffer 
wrote:
 On Wed, 12 Mar 2014 08:32:14 -0400, Michel Fortin 
 <michel.fortin michelf.ca> wrote:

 On 2014-03-12 03:04:38 +0000, Manu <turkeyman gmail.com> said:

 virtual-by-default is incompatible with optimisation, and 
 it's reliable to
 assume that anybody who doesn't explicitly care about this 
 will stick with
 the default, which means many potentially useful libraries 
 may be
 eliminated for use by many customers.
I'll add another argument to the mix. Currently, you can't have private/package functions that are virtual, contrary to what TDPL says. To make things coherent we could change private function so they become virtual by default. You might be able to see the problem with this option: making private function virtual by default is likely to add many performance regressions in existing code, silently.
Private virtual functions make 0 sense. A private function cannot be accessed by a derived class. Who gets to access a overriden virtual function? The base class only? If I'm writing a function, I certainly should be able to access it, no? Even if you want to restrict my access, you cannot, I'm in control of that code! Package, I'm less concerned about. You can make that virtual, I don't ever use package functions. -Steve
Private virtual functions actually make a LOT of sense in C++. Ever heard of NVI? It is actually good design practice to make class virtuals private in many cases and relay on Template Method pattern. Even Andrei advices that in C++ Coding Standards.
Mar 12 2014
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 3/12/14, Michel Fortin <michel.fortin michelf.ca> wrote:
 Currently, you can't have private/package functions that are virtual,
 contrary to what TDPL says.
The last word from Walter was that he agreed tying access specifiers to virtuality is wrong, but that it needs a proper DIP.
Mar 12 2014
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 12 March 2014 at 12:32:14 UTC, Michel Fortin wrote:
 I'll add another argument to the mix.

 Currently, you can't have private/package functions that are 
 virtual, contrary to what TDPL says.

 To make things coherent we could change private function so 
 they become virtual by default. You might be able to see the 
 problem with this option: making private function virtual by 
 default is likely to add many performance regressions in 
 existing code, silently.
No. In the case of private functions, by definition, the compiler have all overrides in the module and can finalize what needs to be.
 We could always keep things as they currently are: 
 private/package is not virtual, everything else is virtual 
 unless marked final. Honestly I'd like to se that go. The 
 protection attribute should have nothing to do with whether a 
 function is virtual or not.
That is horrible. Bad separation of concerns.
Mar 12 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/11/14, 8:04 PM, Manu wrote:
 I'm really trying to keep my lid on here...
Yep, here we go again :o).
 I'll just remind that in regard to this particular point which sounds
 reasonable, it's easy to forgot that *all library code where the author
 didn't care* is now unusable by anybody who does. The converse would not
 be true if the situation was reversed.
There's an asymmetry introduced by the fact there's today code in use.
 virtual-by-default is incompatible with optimisation, and it's reliable
 to assume that anybody who doesn't explicitly care about this will stick
 with the default, which means many potentially useful libraries may be
 eliminated for use by many customers.
Virtual by default is, however, compatible with customization and flexibility. Unstated assumption: "many potential useful libraries" assumes many libraries use traditional OO design in their core components. Unstated assumption: "many customers".
 Also, as discussed at length, revoking virtual from a function is a
 breaking change, adding virtual is not.
Changing the default is a breaking change.
 Which means that, instead of
 making a controlled breaking change with a clear migration path here and
 now, we are committing every single instance of any user's intent to
 'optimise' their libraries (by finalising unnecessarily virtuals) to
 breaking changes in their ABI - which *will* occur, since virtual is the
 default.
Unstated assumption: "every single instance" assumes again that people interested in writing fast libraries have virtual calls as a major bottleneck, and furthermore they didn't care about speed to start with, to wake up later. This pictures library designers as quite incompetent people.
 According to semantic versioning, this requires bumping the major
 version number... that's horrible!
Appeal to emotion.
 What's better; implementing a controlled deprecation path now, or
 leaving it up to any project that ever uses the 'class' keyword to
 eventually confront breaking changes in their API when they encounter a
 performance oriented customer?
It's better to leave things be. All I see is the same anecdote gets vividly told again whenever the topic comes up. Andrei
Mar 12 2014
parent Manu <turkeyman gmail.com> writes:
On 13 March 2014 03:47, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org>wrote:

 On 3/11/14, 8:04 PM, Manu wrote:

 I'm really trying to keep my lid on here...
Yep, here we go again :o).
*sigh* I'll just remind that in regard to this particular point which sounds
 reasonable, it's easy to forgot that *all library code where the author
 didn't care* is now unusable by anybody who does. The converse would not
 be true if the situation was reversed.
There's an asymmetry introduced by the fact there's today code in use.
Do you think the deprecation path is particularly disruptive? It can be implemented over a reasonably long time. virtual-by-default is incompatible with optimisation, and it's reliable
 to assume that anybody who doesn't explicitly care about this will stick
 with the default, which means many potentially useful libraries may be
 eliminated for use by many customers.
Virtual by default is, however, compatible with customization and flexibility.
I completely disagree with the everything-should-be-virtual idea in principle; I think it's dangerous and irresponsible API design, but that's my opinion. Whether you are into that or not, I see it as a design decision, and I think it's reasonable to make that decision explicit by typing 'virtual:'. What's not subjective, is that the optimiser can't optimise virtual-by-default. That's just a fact, and one which I care about deeply. I think it's also statistically reliable that people will stick with the default in almost all cases. Unstated assumption: "many potential useful libraries" assumes many
 libraries use traditional OO design in their core components.
In my experience; physics, sound, scene graph... these sorts of things are common libraries, and also heavy users of OO. Each of those things are broken into small pieces implemented as many objects. If people then make use of properties, we're in a situation which is much worse than what we already struggle with in C++. Unstated assumption: "many customers". Do I need to quantify? I work in a gigantic industry. You might call it niche, but it's like, really, really big. I often attend an annual conference called GDC which attracts multiple 10s of thousands of developers each year. It's probably the biggest software developer conference in the world. A constantly recurring theme at those conferences is low-level performance on embedded hardware, and specifically, the mistakes that PC developers make when first moving to embedded architectures. There's a massive audience for these topics, because everyone is suffering the same problems. Virtual is one of the most expensive hazards, just not on x86. Most computers in the world today don't run x86 processors. Also, as discussed at length, revoking virtual from a function is a
 breaking change, adding virtual is not.
Changing the default is a breaking change.
Yes, but there is an opportunity for a smooth transition and elimination of the problem, rather than committing to consistent recurrence of breaking libraries in the future whenever anyone wants to optimise in this way. Which means that, instead of
 making a controlled breaking change with a clear migration path here and
 now, we are committing every single instance of any user's intent to
 'optimise' their libraries (by finalising unnecessarily virtuals) to
 breaking changes in their ABI - which *will* occur, since virtual is the
 default.
Unstated assumption: "every single instance" assumes again that people interested in writing fast libraries have virtual calls as a major bottleneck, and furthermore they didn't care about speed to start with, to wake up later. This pictures library designers as quite incompetent people.
YES! This is absolutely my professional experience! I've repeated this many times. Many(/most) libraries I've wanted to use in the past are written for a PC; rarely any real consideration for low-level performance. Those that are tested for cross-compiling are often _originally_ written for a PC; API is architecturally pre-disposed to poor performance. This is precisely the sort of thing that library authors don't care about until some subset of customers come along that do. At that point, they are faced with a conundrum; breaking the API or ignoring the minority - which can often take years to resolve, meanwhile buggering up our schedule or wasting our time re-inventing some wheel. PC programmers are careless programmers on average. Because x86 is the most tolerant architecture WRT low-level performance by far, unless library authors actively test their software on a wide variety of machines, they have no real bearing to judge their code. According to semantic versioning, this requires bumping the major
 version number... that's horrible!
Appeal to emotion.
Bumping major version numbers is not an emotional expression. People take semantic versioning very seriously. What's better; implementing a controlled deprecation path now, or
 leaving it up to any project that ever uses the 'class' keyword to
 eventually confront breaking changes in their API when they encounter a
 performance oriented customer?
It's better to leave things be. All I see is the same anecdote gets vividly told again whenever the topic comes up.
Whatever.
Mar 12 2014
prev sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Tuesday, 11 March 2014 at 18:35:57 UTC, Dicebot wrote:
 On Tuesday, 11 March 2014 at 18:29:35 UTC, Steve Teale wrote:
 On Tuesday, 11 March 2014 at 18:14:52 UTC, Steven 
 Schveighoffer wrote:
 On Tue, 11 Mar 2014 13:47:55 -0400, Steve Teale
Functions final by default? I read the list of changes for 2.065, and that one got by me completely. Aargh!
Not in 2.065 2.066 will introduce "virtual" keyword 2.067+ will change the defaults if it will still be considered good idea
Have a link to where that was decided? I was under the impression that virtual was accepted as a compromise so people could just stick "final:" at the top of their classes have have something acceptably close to final-by-default. I can't remember if I actually managed to keep up with that behemoth of a thread though.
Mar 11 2014
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 11 Mar 2014 17:35:20 -0400, Brad Anderson <eco gnuk.net> wrote:

 On Tuesday, 11 March 2014 at 18:35:57 UTC, Dicebot wrote:
 Not in 2.065
 2.066  will introduce "virtual" keyword
 2.067+ will change the defaults if it will still be considered good idea
Have a link to where that was decided? I was under the impression that virtual was accepted as a compromise so people could just stick "final:" at the top of their classes have have something acceptably close to final-by-default. I can't remember if I actually managed to keep up with that behemoth of a thread though.
It was buried in that thread. Here is a bugzilla issue that links to Walter's post. I wasn't aware until recently. Re-reading the thread where Walter agreed, I can't find a clear response from Andrei that he was in agreement or not, but I suspect not (especially after reading his responses here). https://d.puremagic.com/issues/show_bug.cgi?id=11616 Perhaps the feature should be put on hold for now? Haven't heard Walter re-affirm his position. -Steve
Mar 11 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Tuesday, 11 March 2014 at 21:46:05 UTC, Steven Schveighoffer 
wrote:
 It was buried in that thread. Here is a bugzilla issue that 
 links to Walter's post. I wasn't aware until recently. 
 Re-reading the thread where Walter agreed, I can't find a clear 
 response from Andrei that he was in agreement or not, but I 
 suspect not (especially after reading his responses here).

 https://d.puremagic.com/issues/show_bug.cgi?id=11616

 Perhaps the feature should be put on hold for now? Haven't 
 heard Walter re-affirm his position.

 -Steve
There is also actual pull request (which I can't link right now because github is down for me). What I have listed is summary of plans from that bugzilla entry and PR at point where Walter has agreed. Recently Andrei has noticed merged PR and objected to it so what will happen next is unclear.
Mar 11 2014
parent "Dicebot" <public dicebot.lv> writes:
PR: https://github.com/D-Programming-Language/dmd/pull/2895
Mar 11 2014
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 11 Mar 2014 17:35:20 -0400, Brad Anderson <eco gnuk.net> wrote:

 Have a link to where that was decided? I was under the impression that  
 virtual was  accepted as a compromise so people could just stick  
 "final:" at the top of their classes have have something acceptably  
 close to final-by-default. I can't remember if I actually managed to  
 keep up with that behemoth of a thread though.
BTW, I'm somewhat amused that this was as unknown to everyone else as it was to me. I figured because I was away from D for 6 months, I just missed it and everyone was OK with it :) Didn't mean to start another firestorm! -Steve
Mar 11 2014
parent "Dicebot" <public dicebot.lv> writes:
On Tuesday, 11 March 2014 at 21:47:19 UTC, Steven Schveighoffer 
wrote:
 BTW, I'm somewhat amused that this was as unknown to everyone 
 else as it was to me. I figured because I was away from D for 6 
 months, I just missed it and everyone was OK with it :) Didn't 
 mean to start another firestorm!

 -Steve
I only know it because I am subscribed to all activity in dmd repo :)
Mar 11 2014
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Brad Anderson:

 Have a link to where that was decided? I was under the 
 impression that virtual was  accepted as a compromise so people 
 could just stick "final:" at the top of their classes have have 
 something acceptably close to final-by-default.
I have seen D code in the wild where all member functions are virtual, impure and most variables are mutable. Programmers often stick to defaults, even when they are not the best choice. Virtual functions are functions with some extra functionality. When the programmer needs it, he/she/shi asks for it. When it's not needed, the programmer often sticks with what defaults the language designers have chosen. Bye, bearophile
Mar 11 2014
prev sibling parent reply Daniel =?ISO-8859-1?Q?Koz=E1k?= <kozzi11 gmail.com> writes:
Steven Schveighoffer píše v Út 11. 03. 2014 v 14:14 -0400:

 Consider how long Walter resisted the call to make functions final by  
 default, until he suddenly switched sides. I think of it like a  
 dictatorship with 1000 advisors. And no death squads :)
What is the current status of this?
Mar 11 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/11/14, 11:24 AM, Daniel Kozák wrote:
 Steven Schveighoffer píše v Út 11. 03. 2014 v 14:14 -0400:

 Consider how long Walter resisted the call to make functions final by
 default, until he suddenly switched sides. I think of it like a
 dictatorship with 1000 advisors. And no death squads :)
What is the current status of this?
I am opposed to making functions final by default. Andrei
Mar 11 2014
next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Tuesday, 11 March 2014 at 20:16:50 UTC, Andrei Alexandrescu 
wrote:
 On 3/11/14, 11:24 AM, Daniel Kozák wrote:
 Steven Schveighoffer píše v Út 11. 03. 2014 v 14:14 -0400:

 Consider how long Walter resisted the call to make functions 
 final by
 default, until he suddenly switched sides. I think of it like 
 a
 dictatorship with 1000 advisors. And no death squads :)
What is the current status of this?
I am opposed to making functions final by default.
Because of the breakage, or because you think virtual-by-default makes more sense?
Mar 11 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/11/14, 1:18 PM, Vladimir Panteleev wrote:
 On Tuesday, 11 March 2014 at 20:16:50 UTC, Andrei Alexandrescu wrote:
 On 3/11/14, 11:24 AM, Daniel Kozák wrote:
 Steven Schveighoffer píše v Út 11. 03. 2014 v 14:14 -0400:

 Consider how long Walter resisted the call to make functions final by
 default, until he suddenly switched sides. I think of it like a
 dictatorship with 1000 advisors. And no death squads :)
What is the current status of this?
I am opposed to making functions final by default.
Because of the breakage, or because you think virtual-by-default makes more sense?
A combination of both. The change would break a lot of code and it seems to me final vs. virtual by default is a judgment call more than an obvious decision in favor of final. That said, if I'd do things over again I'd advocate final by default. But we're not doing things over again. Andrei
Mar 11 2014
next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Tuesday, 11 March 2014 at 20:23:59 UTC, Andrei Alexandrescu 
wrote:
 On 3/11/14, 1:18 PM, Vladimir Panteleev wrote:
 On Tuesday, 11 March 2014 at 20:16:50 UTC, Andrei Alexandrescu 
 wrote:
 On 3/11/14, 11:24 AM, Daniel Kozák wrote:
 Steven Schveighoffer píše v Út 11. 03. 2014 v 14:14 -0400:

 Consider how long Walter resisted the call to make 
 functions final by
 default, until he suddenly switched sides. I think of it 
 like a
 dictatorship with 1000 advisors. And no death squads :)
What is the current status of this?
I am opposed to making functions final by default.
Because of the breakage, or because you think virtual-by-default makes more sense?
A combination of both. The change would break a lot of code and it seems to me final vs. virtual by default is a judgment call more than an obvious decision in favor of final. That said, if I'd do things over again I'd advocate final by default. But we're not doing things over again. Andrei
You do support the introduction of the virtual keyword though, yes?
Mar 11 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/11/14, 1:45 PM, John Colvin wrote:
 On Tuesday, 11 March 2014 at 20:23:59 UTC, Andrei Alexandrescu wrote:
 On 3/11/14, 1:18 PM, Vladimir Panteleev wrote:
 On Tuesday, 11 March 2014 at 20:16:50 UTC, Andrei Alexandrescu wrote:
 On 3/11/14, 11:24 AM, Daniel Kozák wrote:
 Steven Schveighoffer píše v Út 11. 03. 2014 v 14:14 -0400:

 Consider how long Walter resisted the call to make functions final by
 default, until he suddenly switched sides. I think of it like a
 dictatorship with 1000 advisors. And no death squads :)
What is the current status of this?
I am opposed to making functions final by default.
Because of the breakage, or because you think virtual-by-default makes more sense?
A combination of both. The change would break a lot of code and it seems to me final vs. virtual by default is a judgment call more than an obvious decision in favor of final. That said, if I'd do things over again I'd advocate final by default. But we're not doing things over again. Andrei
You do support the introduction of the virtual keyword though, yes?
If explained a good use case, I would. Andrei
Mar 11 2014
parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2014-03-11 21:16:28 +0000, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 On 3/11/14, 1:45 PM, John Colvin wrote:
 You do support the introduction of the virtual keyword though, yes?
If explained a good use case, I would.
class Foo { final: void bar(); void baz(); virtual: void crack(); void crunch(); final: void dodge(); void damp(); virtual void divert(); void doh(); } -- Michel Fortin michel.fortin michelf.ca http://michelf.ca
Mar 11 2014
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/11/14, 2:28 PM, Michel Fortin wrote:
 On 2014-03-11 21:16:28 +0000, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> said:

 On 3/11/14, 1:45 PM, John Colvin wrote:
 You do support the introduction of the virtual keyword though, yes?
If explained a good use case, I would.
class Foo { final: void bar(); void baz(); virtual: void crack(); void crunch(); final: void dodge(); void damp(); virtual void divert(); void doh(); }
Got it, thanks. If we don't move forward with final by default, this is too little utility to justify adding a keyword. (We could look into making it a contextual keyword.) Andrei
Mar 11 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/11/2014 2:28 PM, Michel Fortin wrote:
 class Foo
 {
 final:
      void bar();
      void baz();

 virtual:
      void crack();
      void crunch();

 final:
      void dodge();
      void damp();
      virtual void divert();
      void doh();
 }
class Foo { final { void bar(); void baz(); } void crack(); void crunch(); final { void dodge(); void damp(); void divert(); void doh(); } } That said, there's still a case for !final.
Mar 12 2014
next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Wednesday, 12 March 2014 at 21:38:03 UTC, Walter Bright wrote:
 On 3/11/2014 2:28 PM, Michel Fortin wrote:
 class Foo
 {
 final:
     void bar();
     void baz();

 virtual:
     void crack();
     void crunch();

 final:
     void dodge();
     void damp();
     virtual void divert();
     void doh();
 }
class Foo { final { void bar(); void baz(); } void crack(); void crunch(); final { void dodge(); void damp(); void divert(); void doh(); } }
Dat indentation/scoping! It works, but it makes my eyes bleed.
Mar 12 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 That said, there's still a case for !final.
It looks bad :-( int foo() nothrow { return 0; } int bar() !throw { return 0; } Bye, bearophile
Mar 12 2014
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
13-Mar-2014 02:02, bearophile пишет:
 Walter Bright:

 That said, there's still a case for !final.
It looks bad :-( int foo() nothrow { return 0; } int bar() !throw { return 0; } Bye, bearophile
~nothrow -- Dmitry Olshansky
Mar 12 2014
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Wednesday, 12 March 2014 at 21:38:03 UTC, Walter Bright wrote:
 On 3/11/2014 2:28 PM, Michel Fortin wrote:
 class Foo
 {
 final:
     void bar();
     void baz();

 virtual:
     void crack();
     void crunch();

 final:
     void dodge();
     void damp();
     virtual void divert();
     void doh();
 }
class Foo { final { void bar(); void baz(); } void crack(); void crunch(); final { void dodge(); void damp(); void divert(); void doh(); } }
With that in mind you can also claim that system <-> safe and public <-> private are redundant. Let us make public default and remove the public keyword: ---- class Foo { private { } //public stuff private { } } ---- Same with safe/ system ;) Long story short: It should always exist the opposite of a keyword meaning, to interrupt it.
Mar 12 2014
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 12 March 2014 at 21:38:03 UTC, Walter Bright wrote:
 On 3/11/2014 2:28 PM, Michel Fortin wrote:
 class Foo
 {
 final:
     void bar();
     void baz();

 virtual:
     void crack();
     void crunch();

 final:
     void dodge();
     void damp();
     virtual void divert();
     void doh();
 }
class Foo { final { void bar(); void baz(); } void crack(); void crunch(); final { void dodge(); void damp(); void divert(); void doh(); } } That said, there's still a case for !final.
I was thinking about ~final, but yes, we need some way to get out of qualifiers like final, override, pure, nothrow, ...
Mar 12 2014
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 12 Mar 2014 17:38:10 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:

 On 3/11/2014 2:28 PM, Michel Fortin wrote:
 class Foo
 {
 final:
      void bar();
      void baz();

 virtual:
      void crack();
      void crunch();

 final:
      void dodge();
      void damp();
      virtual void divert();
      void doh();
 }
class Foo { final { void bar(); void baz(); } void crack(); void crunch(); final { void dodge(); void damp(); void divert(); void doh(); } } That said, there's still a case for !final.
Fixed it for you. class Foo { final { void bar(); void baz(); } void crack(); void crunch(); final { void dodge(); void damp(); } void divert(); final void doh(); } -Steve
Mar 13 2014
prev sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Walter Bright"  wrote in message news:lfqk3r$1rq$1 digitalmars.com... 

 class Foo
 {
    final
    {
       void bar();
       void baz();
    }
 
       void crack();
       void crunch();
 
    final
    {
       void dodge();
       void damp();
       void divert();
       void doh();
    }
 }
 
 That said, there's still a case for !final.
This looks much worse with all the method bodies still in there.
Mar 13 2014
prev sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Andrei Alexandrescu"  wrote in message news:531F70ED.3040304 erdani.org...

On 3/11/14, 1:18 PM, Vladimir Panteleev wrote:

 A combination of both. The change would break a lot of code and it seems 
 to me final vs. virtual by default is a judgment call more than an obvious 
 decision in favor of final. That said, if I'd do things over again I'd 
 advocate final by default. But we're not doing things over again.

 Andrei
FWIW this is exactly where I was back before dconf13. I was convinced when I realized that: - It is impossible for the optimizer to achieve the same performance in all cases thanks to dynamic linking - Linking with C++ usually requires marking _almost_ every method with 'final' - Only the introducing virtual methods need to be changed, so the breakage is actually very small and trivially handled So after 5 minutes of adding 'virtual' where the compiler tells me to, I can delete a whole bunch of cruft from my code and keep the same performance. (Note that those 5 minutes can be done at your leisure over the years it takes for this to progress through the deprecation stages)
Mar 12 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/12/14, 5:20 AM, Daniel Murphy wrote:
 - Only the introducing virtual methods need to be changed, so the
 breakage is actually very small and trivially handled
Most breakages are very small and trivially handled. That's not the point. Andrei
Mar 12 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 Most breakages are very small and trivially handled. That's not 
 the point.
Unexpected regressions, silent dangerous breakage, safe but hard to fix breakage, and carefully planned breakage that can be trivially handled three are very different cases. Bye, bearophile
Mar 12 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/12/14, 10:04 AM, bearophile wrote:
 Andrei Alexandrescu:

 Most breakages are very small and trivially handled. That's not the
 point.
Unexpected regressions, silent dangerous breakage, safe but hard to fix breakage, and carefully planned breakage that can be trivially handled three are very different cases.
That's why I said "most" and not "all". I think we must take final-by-default off the table. Doing so would also make the addition of "virtual" too much a price to pay for the negation of "final". Andrei
Mar 12 2014
parent Jacob Carlborg <doob me.com> writes:
On 2014-03-12 18:07, Andrei Alexandrescu wrote:

 That's why I said "most" and not "all".

 I think we must take final-by-default off the table. Doing so would also
 make the addition of "virtual" too much a price to pay for the negation
 of "final".
There has previously been suggestions of adding syntax turn off/negating attributes. Something like: class Foo { final: !final void foo () {} } -- /Jacob Carlborg
Mar 12 2014
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 I am opposed to making functions final by default.
Walter has agreed to make functions final by default. And this now compiles: class Foo { virtual void bar() {} } void main() {} I think it's a change for the better. Are we changing direction again? Do you want to remove the virtual keyword again? I am confused. Bye, bearophile
Mar 11 2014
prev sibling parent "Brian Rogoff" <brogoff gmail.com> writes:
On Tuesday, 11 March 2014 at 18:33:16 UTC, Daniel Kozák wrote:
 Steven Schveighoffer píše v Út 11. 03. 2014 v 14:14 -0400:

 Consider how long Walter resisted the call to make functions 
 final by  default, until he suddenly switched sides. I think 
 of it like a  dictatorship with 1000 advisors. And no death 
 squads :)
If he resisted for a long time, it makes little sense to say "he suddenly switched sides". Reviewing the old thread, it looks like Manu's arguments amongst others were convincing that this change is worth it. I have mixed feelings on this topic. I think methods should be final by default, but it is late in the day for these kind of changes, especially given D's unpleasant history with respect to changes. -- Brian
Mar 11 2014
prev sibling next sibling parent "Joakim" <joakim airpost.net> writes:
On Tuesday, 11 March 2014 at 17:47:56 UTC, Steve Teale wrote:
 What D needs at this point is a dictator. There are about 30 
 pages of discussion about Walter's std.array.front post, and 
 Steve S's counter post.

 It reminds me of the way it was maybe 4 years ago, when there 
 was so much bickering that I just gave up for some time, and 
 went away. Who is going to go through all that stuff, and 
 winnow a compromise out of it. Everyone has a job, or some 
 vital preoccupation with their own project.

 The buck has to stop somewhere - is it Walter, or Andrei, or 
 can any proposal or comment be stalled by sheer weight of 
 contrary views?

 This is probably a management issue, not a technical one. 
 Trouble is there's no manager, and even if their was, he'd have 
 no minions.

 What to do?

 Steve
I like it. :) It's Walter's project and he solicited opinions. Maybe they change his mind, maybe they don't. In this case, it appears they did: he seems to have decided that the breakage wouldn't be worth the speedup. What would you prefer, that Walter The Dictator did it anyway? That's not how communities work. There is no doubt that the buck stops with the core team. If people don't like their decisions, they can and will leave or who knows, fork. If you want someone willing to go against the grain, I have seen others here accuse Walter of being stubborn in the past. I don't think you can say he simply goes with the crowd. ;) I will agree with you on one point though. It's not particularly clear to an outsider what the decision-making process is with D, ie what the deliberative process is and who ultimately decides. If you've been around long enough and check the github pull requests and commits, you can get a sense of it, but the roles are not really defined. I understand most open-source projects work this way, but D is probably big enough now that some exposition is helpful. I think it'd be nice to have a page on dlang.org, whether on the main site or the wiki, that laid out who the core team is, sort of like a masthead in a magazine, with a paragraph or two about each person. This would give newcomers some bearings on who the core team is, what their roles are, and what they do for the project. I'm sure anyone could figure all this out on their own eventually, with enough time spent on the newsgroup and looking at source commits, but the idea is to save them some time. Just my suggestion.
Mar 11 2014
prev sibling next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
11-Mar-2014 21:47, Steve Teale пишет:
 This is probably a management issue, not a technical one. Trouble is
 there's no manager, and even if their was, he'd have no minions.
Good management hardly ever won a contest in design. -- Dmitry Olshansky
Mar 11 2014
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Tuesday, 11 March 2014 at 17:47:56 UTC, Steve Teale wrote:
 What D needs at this point is a dictator. There are about 30 
 pages of discussion about Walter's std.array.front post, and 
 Steve S's counter post.

 It reminds me of the way it was maybe 4 years ago, when there 
 was so much bickering that I just gave up for some time, and 
 went away. Who is going to go through all that stuff, and 
 winnow a compromise out of it. Everyone has a job, or some 
 vital preoccupation with their own project.

 The buck has to stop somewhere - is it Walter, or Andrei, or 
 can any proposal or comment be stalled by sheer weight of 
 contrary views?

 This is probably a management issue, not a technical one. 
 Trouble is there's no manager, and even if their was, he'd have 
 no minions.

 What to do?

 Steve
It already works that way. Only thing is not obvious is actual decision point as it is rarely announced. And as any such topic is inherently controversial, making decision that satisfies everyone is rarely possible and debates often continue even after decision point. To be honest I think real problem is directly the opposite - decision process is too vague and limited by the bottleneck of Andrei & Walter participation. Making it more distributed and formalized can help - and this is more of a technical/tooling issue.
Mar 11 2014
parent reply "Mathias LANG" <pro.mathias.lang gmail.com> writes:
On Tuesday, 11 March 2014 at 19:27:40 UTC, Dicebot wrote:
 It already works that way. Only thing is not obvious is actual 
 decision point as it is rarely announced. And as any such topic 
 is inherently controversial, making decision that satisfies 
 everyone is rarely possible and debates often continue even 
 after decision point.

 To be honest I think real problem is directly the opposite - 
 decision process is too vague and limited by the bottleneck of 
 Andrei & Walter participation. Making it more distributed and 
 formalized can help - and this is more of a technical/tooling 
 issue.
I tend to agree with you. Someone once pointed out that we should set goals for release. Hence, Walter said we should emphasize on ICE for 2.064, and from what I know it turned out to be a good idea. AFAIK no such thing was done for 2.065, neither for DMD or Phobos (or I missed it). For example, you can see that the stream API is quite old and needs replacement: http://dlang.org/library/index.html However, I didn't see anything related to the deprecation, the why and what's needed, neither in the bugzilla (searched both 'stream' and 'std.stream') nor in the DIPs.
Mar 11 2014
parent "bearophile" <bearophileHUGS lycos.com> writes:
Mathias LANG:

 However, I didn't see anything related to the deprecation, the 
 why and what's needed, neither in the bugzilla (searched both 
 'stream' and 'std.stream') nor in the DIPs.
Please add it to bugzilla. Bye, bearophile
Mar 11 2014
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/11/2014 10:47 AM, Steve Teale wrote:
 What D needs at this point is a dictator.
http://www.youtube.com/watch?v=poDaTeyqIm4
Mar 11 2014
parent reply "Steve Teale" <steve.teale britseyeview.com> writes:
On Tuesday, 11 March 2014 at 20:43:07 UTC, Walter Bright wrote:
 On 3/11/2014 10:47 AM, Steve Teale wrote:
 What D needs at this point is a dictator.
http://www.youtube.com/watch?v=poDaTeyqIm4
Ace Walter - how do you find the time? I believe that you are becoming truly benevolent as you grow older ;=)
Mar 12 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/12/2014 12:03 AM, Steve Teale wrote:
 Ace Walter - how do you find the time? I believe that you are becoming truly
 benevolent as you grow older ;=)
I rely on the fresh blood of unborn kittens.
Mar 12 2014
parent "Steve Teale" <steve.teale britseyeview.com> writes:
On Wednesday, 12 March 2014 at 23:53:52 UTC, Walter Bright wrote:
 I rely on the fresh blood of unborn kittens.
I must try it. Sadly our youngest cat has disappeared over about 4 days now, and we're feeling worried.
Mar 13 2014
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Tuesday, 11 March 2014 at 17:47:56 UTC, Steve Teale wrote:
 What D needs at this point is a dictator. There are about 30 
 pages of discussion about Walter's std.array.front post, and 
 Steve S's counter post.

 It reminds me of the way it was maybe 4 years ago, when there 
 was so much bickering that I just gave up for some time, and 
 went away. Who is going to go through all that stuff, and 
 winnow a compromise out of it. Everyone has a job, or some 
 vital preoccupation with their own project.

 The buck has to stop somewhere - is it Walter, or Andrei, or 
 can any proposal or comment be stalled by sheer weight of 
 contrary views?

 This is probably a management issue, not a technical one. 
 Trouble is there's no manager, and even if their was, he'd have 
 no minions.

 What to do?

 Steve
I think the only thing lacking—and some people already alluded to this—is a formalized DIP process that results in acceptance or rejection. The DIPs are kind of becoming an idea graveyard. The long community discussions are just a sign of a health community trying to address hard problems with no clear right or wrong answer. I'm happy with the leadership roles D has. They tend to only step in on serious matters, not little disagreements over design decisions that don't affect the big picture. A much more heavy handed approach would probably alienate the community. http://wiki.dlang.org/DIPs
Mar 11 2014
prev sibling next sibling parent "Joseph Cassman" <jc7919 outlook.com> writes:
On Tuesday, 11 March 2014 at 17:47:56 UTC, Steve Teale wrote:
 What D needs at this point is a dictator. There are about 30 
 pages of discussion about Walter's std.array.front post, and 
 Steve S's counter post.

 It reminds me of the way it was maybe 4 years ago, when there 
 was so much bickering that I just gave up for some time, and 
 went away. Who is going to go through all that stuff, and 
 winnow a compromise out of it. Everyone has a job, or some 
 vital preoccupation with their own project.

 The buck has to stop somewhere - is it Walter, or Andrei, or 
 can any proposal or comment be stalled by sheer weight of 
 contrary views?

 This is probably a management issue, not a technical one. 
 Trouble is there's no manager, and even if their was, he'd have 
 no minions.

 What to do?

 Steve
I started trying to use D a few years ago and also had to take a long hiatus due to frustration with its quality of implementation. But having come back to it a little over a year ago I think it is now generally useable and ready for the final polishing effort needed to make it into a professional product. A lot of that success I feel is due to the good leadership of Walter and Andrei. Even though they are the "dictators" so to speak of the language, they are very open to discussion and have good taste when it comes to what to include in the language. I learn a lot from the forums and appreciate being able to discuss things with those involved in developing the language. Still something needs to happen to get D to the next million people. The current grassroots structure has served D well. And I think its legacy should continue forward no matter what form D's development takes. But along with its current set of developers I think that D really needs some solid financial support. In particular, I think that there needs to be a good group of full-time developers on the payroll to kick its development into high gear. I have no ability to organize such an effort, pay for it, or even join as a developer. But whatever could be done to get funded development into action would be well worth it in my opinion. I fear that without such an organized effort the promise that D currently holds may fade into niche irrelevance as time passes on. When I saw the talks scheduled for Dconf 2014 "Opening Keynote: State of the struct address" by Andrei and "Keynote: The Last Thing D Needs" by Scott Meyers I was hoping that perhaps this will be announced as something already in the works. Not sure what that conference will bring. But would be pretty cool if so. Joseph
Mar 11 2014
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 3/11/14, Steve Teale <steve.teale britseyeview.com> wrote:
 What D needs at this point is a dictator.
You see these massive protests and overthrows of people who hold absolute power around the world, and you think D needs a dictator. I'm really baffled at some people.
Mar 13 2014