On Thursday, 13 March 2014 at 15:57:22 UTC, Andrei Alexandrescu wrote:
> At a level it's clear it's not a matter of right or wrong but instead a judgment call, right? Successful languages go with either default.
>
> Andrei

For what it's worth, "education" could help solve this problem: For example, "people" where surprised by the context pointer in nested structs, and now (I think), it is (or will become) second nature to always type:

static struct S
{...}

Heck, I even do it for my global structs too now.

So maybe the issue could be solved by educating to always type (by default):

final class A
{...}

The first step in this direction would be to update the documentation to add said final in as many places where it makes sense, and then to do the same thing to the Phobos code base.

On 3/13/14, 10:21 AM, Paolo Invernizzi wrote:
> On Thursday, 13 March 2014 at 16:41:32 UTC, Andrei Alexandrescu wrote:
>> On 3/13/14, 9:23 AM, Daniel Murphy wrote:
>>
>>> This thread has had people from several 'industry' D users stating that
>>> they do not have a problem with well planned breaking changes, and I'm
>>> not sure why you feel differently about this.
>>
>> I have seen those messages as well. I have argued at length why I feel
>> differently about this, including how I see the numbers working in
>> this forum. As far as I can tell you are not convinced, so repeating
>> those arguments would not help.
>
> I think that this it's a bit unfair.
>
> Just to be clear, we have committed a lot of money and effort in the D
> programming language, "smelling" years ago that it could be a
> competitive advantage over other choices.

I think that holds regardless of the decision in this particular matter.

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

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

> 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?
>
> That's my feedback for the community, and for the two leaders.
>
> - Paolo
>
> [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???

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.


Thanks,

Andrei

On 3/13/14, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> 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.

Voting.

On Thursday, 13 March 2014 at 13:37:52 UTC, Dicebot wrote:
> On Thursday, 13 March 2014 at 13:16:54 UTC, Daniel Murphy wrote:
>> "Steven Schveighoffer"  wrote in message news:op.xcnu55j2eav7ka@stevens-macbook-pro.local...
>>
>>> > The worst breaking change in D2, by far, is the prevention of array stomping.
>>>
>>> What is your use case(s), might I ask? Prevention of array stomping, I thought, had a net positive effect on performance, because it no longer has to lock the GC for thread-local appends.
>>
>> I would guess they're setting length to zero and appending to re-use the memory.
>
> Exactly. So far looks like upon transition to D2 almost all arrays used in our code will need to be replaced with some variation of Appender!T

From what little I have read about sociomantic's codebase (pre-allocated lumps of memory, stomped all over to keep code simple and prevent needing extra allocations, am I right?), I would imagine you would be better off just emulating the old behaviour in a little wrapper around a builtin array.

On Thursday, 13 March 2014 at 18:03:42 UTC, Andrej Mitrovic wrote:
> On 3/13/14, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>> 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.
>
> Voting.

I recall someone telling me already that this is not a democracy. Even if we had it I think some sane person would have to make a choice on a 51/49 decision to change something. It would have to be 75% or whatever.

Who is to write the constitution?

Steve

On 12 Mar 2014 22:50, "Walter Bright" <newshound2@digitalmars.com> wrote:
>
> The argument for final by default, as eloquently expressed by Manu, is a
good one. Even Andrei agrees with it (!).
>
> The trouble, however, was illuminated most recently by the std.json
regression that broke existing code. The breakage wasn't even intentional; it was a mistake. The user fix was also simple, just a tweak here and there to user code, and the compiler pointed out where each change needed to be made.
>
> But we nearly lost a major client over it.
>

std.json isn't precisely on the list of modules that showcase Phobos in a good light.  We'd be better off giving the module some TLC and update the API so it's consistent with the rest of Phobos in regards to coding standards and unittest coverage.

> 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.)
>
> Instead, one can write:
>
>    class C { final: ... }
>
> as a pattern, and everything in the class will be final. That leaves the
"but what if I want a single virtual function?" There needs to be a way to locally turn off 'final'. Adding 'virtual' is one way to do that, but:
>
> 1. there are other attributes we might wish to turn off, like 'pure' and
'nothrow'.
>
> 2. it seems excessive to dedicate a keyword just for that.
>
> So, there's the solution that has been proposed before:
>
>    !final
>    !pure
>    !nothrow
>    etc.

Yuck.

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

On 3/13/14, 11:03 AM, Andrej Mitrovic wrote:
> On 3/13/14, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>> 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.
>
> Voting.

Voting is for making a decision, not for conveying it. Voting in programming design matters has two issues:

1. Representation: the set of people on the D forum is too informal a representative. International standardization bodies do use voting, but their framework is considerably more formal (not to mention they have their own liabilities).

2. There's the danger of getting into a design-by-committee rut.


Andrei

On 3/13/2014 6:23 AM, Daniel Murphy wrote:
> For some reason Walter has decided

I've expounded on this at length, it is not "some reason".

On Thursday, 13 March 2014 at 18:13:29 UTC, Steve Teale wrote:
> On Thursday, 13 March 2014 at 18:03:42 UTC, Andrej Mitrovic wrote:
>> On 3/13/14, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>>> 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.
>>
>> Voting.
>
> I recall someone telling me already that this is not a democracy. Even if we had it I think some sane person would have to make a choice on a 51/49 decision to change something. It would have to be 75% or whatever.
>
> Who is to write the constitution?
>
> Steve

Technically, this is a democracy. Nobody is forcing anyone to do
or use anything. Anyone can do a modified version of D and
whoever likes it uses it. This is true democracy.

I think you are confusing democracy and dictatorship of the majority.