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