On Thu, 13 Mar 2014 09:54:55 -0400, Daniel Murphy <yebbliesnospam@gmail.com> wrote:

> "Steven Schveighoffer"  wrote in message news:op.xcnxdfikeav7ka@stevens-macbook-pro.local...
>
>> Are they using assumeSafeAppend? If not, totally understand. If they are, then I want to fix whatever is wrong.
>
> Well no, it's D1 code.

Right. I wasn't sure if an attempt was made to convert and they considered that option usable or not.

Considering the mechanism that is used to "reset" buffers, I would expect it to be a difficult process to update to use assumeSafeAppend. But I would expect the performance to actually increase once that is done.

-Steve

"Steven Schveighoffer"  wrote in message news:op.xcnxwzc8eav7ka@stevens-macbook-pro.local...

> I would also mention that a "band-aid" fix, if you are always using x.length = 0, is to special case that in the runtime to automatically reset the used size to 0 as well. This is a specialized application, I would think tweaking the runtime is a possibility, and a temporary fix like this until you can update your code would at least provide an intermediate solution.

That would risk breaking code in druntime/phobos. 

On Thu, 13 Mar 2014 09:59:41 -0400, Daniel Murphy <yebbliesnospam@gmail.com> wrote:

> "Steven Schveighoffer"  wrote in message news:op.xcnxwzc8eav7ka@stevens-macbook-pro.local...
>
>> I would also mention that a "band-aid" fix, if you are always using x.length = 0, is to special case that in the runtime to automatically reset the used size to 0 as well. This is a specialized application, I would think tweaking the runtime is a possibility, and a temporary fix like this until you can update your code would at least provide an intermediate solution.
>
> That would risk breaking code in druntime/phobos.

I think it would be highly unlikely. Consider the use case:

arr contains some number of elements;
someOtherArr = arr;
arr.length = 0;

...

arr ~= ...;

use someOtherArr, which now has stomped data.

Now, if the code means to reuse the buffer, it will call assumeSafeAppend, which in this case would be a noop, and things will continue to work as expected. If it just relies on the runtime re-allocating arr on the next append, why not just do arr = null? If the code doesn't have someOtherArr, then it will still work just fine. I can't see a reason to reset the length to 0 if you aren't going to reuse the array bytes, instead of setting it to null.

If the code doesn't always reset to length 0, and then tries appending, then Sociomantic's code will still be poorly performing. But I'm assuming it's always length = 0. I would ONLY trigger on that condition (and the array has to be starting at the beginning of the block, I should have mentioned that).

I think it would work without issue. In fact, I wonder if that shouldn't be a "feature" of the array runtime anyway.

-Steve

Suliman:

> It's maybe not proper topic but maybe someone disagreed with current way of D may interesting to continue Amber project. https://bitbucket.org/larsivi/amber/commits/all

From this page:
https://bitbucket.org/larsivi/amber/wiki/Diff_D1

> No comma expression

We could and should disallow some usages of the comma operator in D2 too.


> A class with no constructors inherits the base class constructors, if any.

Is this a good idea?


> synchronized will be deprecated, and is already now just an alias to the guard statement
> Struct-interfaces
> guard-statement

?

Bye,
bearophile

"Steven Schveighoffer"  wrote in message news:op.xcnyu21leav7ka@stevens-macbook-pro.local...

> I think it would work without issue.

Sure, probably.

> In fact, I wonder if that shouldn't be a "feature" of the array runtime anyway.

It breaks the type system when you use it with immutable. 

On Thursday, 13 March 2014 at 04:58:05 UTC, Andrei Alexandrescu wrote:
> I hear you. Time to put this in a nice but firm manner: your arguments were understood but did not convince.

The problem is that this remark could be made in both directions.  I understand some of the motivation for this decision, but the way it's been announced and rationalized is very problematic.

That naturally leads to questions about whether it's the right decision or not, and to be honest, I don't think the follow-ups from you and Walter have adequately addressed those concerns.

Problem 1 -- the announcement as made gives the impression that a known, planned, desirable breaking change with a well-defined deprecation path is to be cancelled because of a client's response to an unplanned and unannounced breakage.  You need to make the case for why well-signposted, well-executed deprecation paths are a problem that sits on the same level as the kind of unexpected breakage this client encountered.

Problem 2 -- perhaps there's a broader context that you can't discuss with us because of commercial confidentiality, but the impression given is that this decision has been taken substantially in reaction to one bad client response.  This gives the impression of a knee-jerk reaction made under stress rather than a balanced decision-making process.  More so because it's not clear if the client would have the same problem with a well-executed deprecation process.

Problem 3 -- I don't think this decision has adequately acknowledged the original rationale for favouring final-by-default.  Walter has discussed the speed concern, but that was not the killer argument -- the one which swung the day was the fact that final-by-default makes it easier to avoid making breaking changes in future -- see e.g.:
http://forum.dlang.org/thread/pzysdctqxjadoraeexaa@forum.dlang.org?page=10#post-mailman.246.1386164839.3242.digitalmars-d:40puremagic.com
http://www.artima.com/intv/nonvirtualP.html

So, if avoiding breaking change in future is a strong goal, allowing the transition to final-by-default is a clear contribution to that goal.

Finally, I'd say that to my mind, these kinds of announcements-by-fiat that come out of the blue and without warning, while not as bad as unexpected code breakage, are still pretty bad for the D user community.  We need to be able to have trust in the firm decisions and understandings reached here in community discussions, that either they will be adhered to or that there will be prior notice and discussion before any counter-decision is finalized.  This is as much part of stability and reliability as the code in the compiler and the libraries.

Best wishes,

    -- Joe

On Thu, 13 Mar 2014 10:29:48 -0400, Daniel Murphy <yebbliesnospam@gmail.com> wrote:

> "Steven Schveighoffer"  wrote in message news:op.xcnyu21leav7ka@stevens-macbook-pro.local...
>
>> I think it would work without issue.
>
> Sure, probably.
>
>> In fact, I wonder if that shouldn't be a "feature" of the array runtime anyway.
>
> It breaks the type system when you use it with immutable.

This is true. We could restrict it only to mutable arrays (I get the type in via its typeinfo).

-Steve

On Thursday, 13 March 2014 at 12:01:15 UTC, Daniel Murphy wrote:
> "Don"  wrote in message news:ekymfpqyxasvelcixrjp@forum.dlang.org...
>
>> I agree completely.
>>
>> Some things that really should be fixed, don't get fixed because of a paranoid fear of breaking code. And this tends to happen with the issues that can give nice warning messages and are easy to fix...
>
> As usual I agree with every single thing in this post, and Sean's. Regressions are bad but have nothing to do with using slow, controlled deprecation to make the language better.

It might be worthwhile to consider a compiler switch which would require forced virtual/final annotations on all methods as per

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

While code compiled with such a switch would be a bit more verbose, it would ensure that programmers were careful with virtual. It was a good transition plan, and the idea has value even if the final by default is delayed or abandoned.

I'd like to see final by default in D rather than it's successor. It seems quite a bit easier to fix than some other unfortunate default choices.

On 3/13/14, 1:43 AM, Don wrote:
> The worst breaking change in D2, by far, is the prevention of array
> stomping.
>
> After that change, our code still runs, and produces exactly the same
> results, but it is so slow that it's completely unusable. This one of
> the main reasons we're still using D1.

Interesting. Are there ways to refactor around this issue without a major redesign?

Andrei

On 3/13/14, 2:15 AM, John Colvin wrote:
> On Thursday, 13 March 2014 at 04:58:05 UTC, Andrei Alexandrescu wrote:
>> I hear you. Time to put this in a nice but firm manner: your arguments
>> were understood but did not convince. The matter has been settled.
>> There will be no final by default in the D programming language. Hope
>> you understand.
>>
>>
>> Thanks,
>>
>> Andrei
>
> In light of this and as a nod to Manu's expertise and judgment on the
> matter:
>
> We should make his reasoning on the importance of deliberately choosing
> virtual vs private in API-public classes prominent in documentation,
> wikis, books and other learning materials.
>
> It may not be an important enough to justify a large language break, but
> if Manu says it is genuinely a problem in his industry, we should do our
> best to alleviate as much as is reasonable.

I think that's a great idea.

Andrei