On Thursday, 13 March 2014 at 18:37:36 UTC, Paolo Invernizzi wrote:
> On Thursday, 13 March 2014 at 17:56:09 UTC, Andrei Alexandrescu wrote:
>> On 3/13/14, 10:21 AM, Paolo Invernizzi wrote:
>>
>>> Told that, I'm following the forum as this is by far the best way to
>>> reinforce of undermine my past decision (and sleep well at night!)
>>> That why I think that, IMHO, companies that adopted D "seriously" are
>>> present here, and are lurking.
>>
>> I don't think so. This isn't the case for my employer, and hasn't been the case historically for a lot of the companies using other languages. I have plenty of experience with forum dynamics to draw from.
>
> So we disagree on that, and that's fine to me, but this don't change the fact your presence here turns  your employer Facebook well represented in the forum now that it has something committed with D, IMHO...
>
>>> Just to give a perspective, we are not so big like Sociomantic but we
>>> are making some $M, so for us the decision was not a joke.
>>
>> Again, it's unlikely the decision would have been in other way affected by a minor language design detail.
>>
>> The matter is you seem convinced final would improve your use of D, and therefore are unhappy with the decision. For those who aren't, we'd seem flaky by breaking their code.
>
> As I've stated, it is not about the single decision, I don't care about final vs virtual in our code. it's about the whole way that "planned improvement" changes to the language are managed.
>
>>> And to be honest what it's really scaring it's not the frequency of the
>>> "planned improvement" of the language, but that a feeling turned  "a
>>> solid piece of evidence" [1] into smoke. Today is virtual, tomorrow how
>>> knows?
>>>
>>> [1]
>>> http://forum.dlang.org/thread/yzsqwejxqlnzryhrkfuq@forum.dlang.org?page=23#post-koo65g:241nqs:242:40digitalmars.com
>>
>> Now I think you're being unfair. Yes, it was a good piece of evidence. And yes, it turned out to be not enough. It's that simple and that visible. What, are Walter and me doing cover-up machinations now???
>
> I'm not a native english speakers, but It doesn't seems to me that the meaning of what I wrote was that D is driven by a machinations.
>
> What I was meaning is: why the past mega-thread about virtual vs final (that I don't care about!) that seemed (to me!) that placed a concrete direction goal was (to me!) scraped like a thunder in clean sky.
>
> Where's the discussion why "it turned out to be not enough"?
>
> What scares me (as a company using the language) was that I wasn't able to "grasp" that fact in forum till now.
>
> So, that could also happen to *other* aspect of the language that a care for my business, without even having the ability do discuss about the motivation of a decision.
>
>> There must be a way to convey that a decision has been made. It is understood it won't please everybody, just like going the other way won't please everybody. Please let me know what that way is.
>
> Again, the whole point was that it seemed to me that a decision was taken in that famous thread.
>
> My feedback, take it as you want Andrei, it is that such behaviours are a way more scaring that the hole point of managing a "planned" (again!) language change.
>
> Thanks,
> - Paolo


This is still at DRAFT status: http://wiki.dlang.org/DIP51

If this was in the "Accepted" state I would agree with your concerns.

I'd like to see DIPs and the Phobos Review Queue extended to cover all language changes and improvements, ignoring bug fixes. It might be the case now, but there is no way to tell ... at least as a D user.

The 2065 Change Log has 10 language changes, 1 compiler change and 4 library changes with no reference to a DIP or Phobos Review. The Change Log does reference DIP37 twice, but they are both bug fixes so it doesn't count :)

There should be a DIP for Walter's proposal in this thread, even if the decision has already been made. Also DIP51 status should be changed to "Rejected" with an paragraph explaining why it was rejected, and possibly a link back to the forum for the gory discussion details.

Cheers,
ed

"Walter Bright"  wrote in message news:lft8ok$2epl$1@digitalmars.com...

> Also,
>
>      class C { final: ... }
>
> achieves final-by-default and it breaks nothing.

No, it doesn't, because it is not usable if C introduces any virtual methods.

On the other hand,

class C { virtual: ... }

_does_ trivially bring back virtual-by-default.

The idea that over the course of (at least) a year, having to add this to some of your classes (that the compiler identifies) is large and unacceptable breakage is just nonsense.

Eg In dmd's OO-heavy code, ~13% of the classes introduce a virtual method. In those 44 classes, every single non-virtual method needs to be marked as final (~700 methods) 

On Wednesday, 12 March 2014 at 22:50:00 UTC, Walter Bright wrote:
> We're past the point where we can break everyone's code. It's going to cost us far, far more than we'll gain. (And you all know that if we could do massive do-overs, I'd get rid of put's auto-decode.)

I figure I'll throw in my thoughts (not to convince you of what is right). I don't have a bread and butter program in D, mainly just hobby.

I don't agree with the choice behind making this flop. I was surprised to find out that the final-by-default had been approved to begin with, you were already aware of the desire to not "break everyone's code," pushing for it throughout discussions. But eventually something made you change your mind, and now a very different situation made you change it back.

D2 shouldn't be arbitrarily frozen like was done with D1. There are things which need to be done and things which should be done, some of which aren't even known yet. It doesn't sound like the intention is to go this far, so I'm hoping this is common ground that some of this stuff will break a lot of code. But we are scared because D1 got the "stable" treatment and that meant things remained broken.

D has had a history of random breaking changes (great work on killing most regressions before release), but planned/expected breaking changes still don't get the upgrade path they deserve. Daniele said it best, the code should compile with the current release and the next release, or more. Meaning old code complies with the new compiler, and changes to remove the use of deprecation should compile with the older compiler. (This allows local builds to update code for a new compiler while the automated builds continue to build the same code with older compiler)

If we can do this, and even extend it out for longer than "next" release we're providing a good upgrade path. This will likely lead to pleasing the majority of users that need require stability, even if the change doesn't appear to be worth it (the current final-by-default may not be worth it from a breaking code point of view, but seems to be considered the "right thing").

> So, there's the solution that has been proposed before:
>
>    !final
>    !pure
>    !nothrow
>    etc.

I think this is ok, I'm also ok with the introduction of new keywords, preferably not, not_nothrow. !nothrow isn't great, but oh well.

On 14 March 2014 06:09, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>wrote:

> On 3/13/14, 11:37 AM, Paolo Invernizzi wrote:
>
>> As I've stated, it is not about the single decision, I don't care about final vs virtual in our code. it's about the whole way that "planned improvement" changes to the language are managed.
>>
>
> Got it, thanks.
>
>
>  What I was meaning is: why the past mega-thread about virtual vs final
>> (that I don't care about!) that seemed (to me!) that placed a concrete
>> direction goal was (to me!) scraped like a thunder in clean sky.
>>
>> Where's the discussion why "it turned out to be not enough"?
>>
>> What scares me (as a company using the language) was that I wasn't able to "grasp" that fact in forum till now.
>>
>> So, that could also happen to *other* aspect of the language that a care for my business, without even having the ability do discuss about the motivation of a decision.
>>
>>  There must be a way to convey that a decision has been made. It is
>>> understood it won't please everybody, just like going the other way won't please everybody. Please let me know what that way is.
>>>
>>
>> Again, the whole point was that it seemed to me that a decision was taken in that famous thread.
>>
>> My feedback, take it as you want Andrei, it is that such behaviours are a way more scaring that the hole point of managing a "planned" (again!) language change.
>>
>
> Understood. That's one angle. The other angle is that a small but vocal faction can intimidate the language leadership to effect a large breaking change that it doesn't believe in.
>

I feel like this was aimed at me, and I also feel it's unfair.

If you recall back to the first threads on the topic, I was the absolute
minority, almost a lone voice. Practically nobody agreed, infact, there was
quite aggressive objection across the board, until much discussion about it
has passed.
I was amazed to see in this thread how many have changed their minds from
past discussions. Infact, my impression from this thread is that the change
now has almost unanimous support, and by my recollection, many(/most?) of
those people were initially against.

To say this is a small vocal faction is unfair (unless you mean me
personally?). A whole bunch of people who were originally against, but were
convinced by argument and evidence is not a 'faction' with an agenda to
intimidate their will upon leadership.
I suspect what seems strange to the participants in this thread, that
despite what eventually appears to have concluded in almost unanimous
agreement (especially surprising considering the starting point years
back!), is the abrupt refusal.
That's Walter's prerogative I guess... if he feels that strongly about it,
then I'm not going to force the issue any more.

I am surprised though, considering the level of support for the change
expressed in this thread, which came as a surprise to me; it's the highest
it's ever been... much greater than in prior discussions on the topic.
You always say forum participation is not a fair representation of the
community, but when the forum representation is near unanimous, you have to
begin to be able to make some assumptions about the wider communities
opinion.

Back to pushing the ARC wagon for me...

Also let's not forget that a bunch of people will have not had contact with
> the group and will not have read the respective thread. For them -- happy campers who get work done in D day in and day out, feeling no speed impact whatsoever from a virtual vs. final decision -- we are simply exercising the brunt of a deprecation cycle with undeniable costs and questionable (in Walter's and my opinion) benefits.

On 14 March 2014 07:42, Walter Bright <newshound2@digitalmars.com> wrote:

> On 3/13/2014 1:09 PM, Andrei Alexandrescu wrote:
>
>> Also let's not forget that a bunch of people will have not had contact
>> with the
>> group and will not have read the respective thread. For them -- happy
>> campers
>> who get work done in D day in and day out, feeling no speed impact
>> whatsoever
>> from a virtual vs. final decision -- we are simply exercising the brunt
>> of a
>> deprecation cycle with undeniable costs and questionable (in Walter's and
>> my
>> opinion) benefits.
>>
>
> Also,
>
>     class C { final: ... }
>
> achieves final-by-default and it breaks nothing.
>

It does nothing to prevent the library case, or the don't-early-optimise case of implying breaking changes in the future.

Please leave the virtual keyword as commit by Daniel Murphy in there. 'final:' is no use without a way to undo it for the few instances that should be virtual. It also really helps C++ portability.

On 14 March 2014 07:55, Walter Bright <newshound2@digitalmars.com> wrote:

> On 3/13/2014 10:07 AM, Xavier Bigand wrote:
>
>> Maybe if changes are really simple a tool can help? Tools are needed for
>> such
>> kind of refactoring can be done automatically.
>>
>
> Source code "fixers" give me the heebie-jeebies. Besides, this particular fix needed some judgement.
>

I think it depends how it's done. Once upon a time, a tool that just made
changes to a bunch of files, I would agree, is horrible.
These days you have version control, and it would also be easy for the tool
to pop up a merge window to visualise the changes being made.
Theoretically, such a tool could produce a patch rather than modify your
code directly, then you can merge it with your tool of choice, and
visualise what it did in the process.

In fact, that's how to add this feature to DMD that people often ask for;
run the compiler with a special flag that does "upgrade v2.0xx -> 2.0yy",
and have it produce a patch file rather than modify your source.
That's gotta be fairly unobjectionable. I'd say that's an awesome feature,
whereas, like you, I would strongly oppose any feature that directly
updates your code for you.

On 2014-03-13 22:40, Daniel Murphy wrote:
> On the other hand,
>
> class C { virtual: ... }
>
> _does_ trivially bring back virtual-by-default.

is this all it takes? i mean, after switching to final-by-default, going through anybodies codebase and blindly adding virtual at the very beginning of each class definition reestablishes to 100% old behavior?

a regex s&r can probably do this. or a tiny tool. this is a step everyone can readily subscribe to. if it is that easy i don't see any grounds for a too-breaking-change argument.

/det

On Friday, 14 March 2014 at 04:40:56 UTC, captaindet wrote:
> On 2014-03-13 22:40, Daniel Murphy wrote:
>> On the other hand,
>>
>> class C { virtual: ... }
>>
>> _does_ trivially bring back virtual-by-default.
>
> is this all it takes? i mean, after switching to final-by-default, going through anybodies codebase and blindly adding virtual at the very beginning of each class definition reestablishes to 100% old behavior?
>
> a regex s&r can probably do this. or a tiny tool. this is a step everyone can readily subscribe to. if it is that easy i don't see any grounds for a too-breaking-change argument.
>
> /det

Yes sure. Including in boilerplate generated via mixins, obviously.

On 3/13/2014 8:40 PM, Daniel Murphy wrote:
> "Walter Bright"  wrote in message news:lft8ok$2epl$1@digitalmars.com...
>
>> Also,
>>
>>      class C { final: ... }
>>
>> achieves final-by-default and it breaks nothing.
>
> No, it doesn't, because it is not usable if C introduces any virtual methods.

That's what the !final storage class is for.

On 3/13/2014 8:56 PM, Manu wrote:
> Please leave the virtual keyword as commit by Daniel Murphy in there. 'final:'
> is no use without a way to undo it for the few instances that should be virtual.

As I stated in the opening in this thread, I understand and agree with the need for a 'virtual' or '!final'. That is not at issue.