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

On 12/03/2014 23:50, Walter Bright wrote:
>> However, it is not possible to get to the "else" part of that version
>> block
>> using the above syntax. Would the same syntax work for version as well?
>>
>>      version(something):
>>          // ...
>>
>>      !version(something):
>>          // ...
>
> Yes, this has come up before, in various forms. The short answer is
> unequivocably "no". I've expounded on this extensively in this n.g., but
> don't have a reference handy.

Some discussion here:
https://d.puremagic.com/issues/show_bug.cgi?id=7417

I understand the argument about not allowing version(X && Y), but I do think this construct is ugly:

version(Foo) {} else { //code

Defining a version identifier NotFoo as well as Foo would be a bad solution.

What's wrong with:

version(!Foo) {}

?

"Nick Treleaven"  wrote in message news:lfsb5c$1kvi$1@digitalmars.com...

> Some discussion here:
> https://d.puremagic.com/issues/show_bug.cgi?id=7417
>
> I understand the argument about not allowing version(X && Y), but I do think this construct is ugly:
>
> version(Foo) {} else { //code
>
> Defining a version identifier NotFoo as well as Foo would be a bad solution.
>
> What's wrong with:
>
> version(!Foo) {}

This is one of the few areas where D is idealistic instead of pragmatic. For some reason Walter has decided unlike most things, this needs to be forced upon everyone.

This reminds me of banning goto and multiple returns because 'structured programming' prevents goto spaghetti madness.  As always, it simply forces the programmer to jump through more hoops to get what they want. 

On Wed, 12 Mar 2014 19:50:14 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> On 3/12/2014 4:14 PM, Ali Çehreli wrote:
>> The same issue came up with 'version' recently. It is possible to start a
>> version block like this:
>>
>>      version(something):
>>
>> However, it is not possible to get to the "else" part of that version block
>> using the above syntax. Would the same syntax work for version as well?
>>
>>      version(something):
>>          // ...
>>
>>      !version(something):
>>          // ...
>
> Yes, this has come up before, in various forms. The short answer is unequivocably "no". I've expounded on this extensively in this n.g., but don't have a reference handy.

Negating version is not the main problem, as one can do version(x){} else{}, which is ugly but effective.

Logical AND is also quite easy with version(x) version(y) {}

The one I would really like to see is logical OR. There is no easy way around this, one must come up with convoluted mechanisms that are much harder to design, write, and understand than just version(x || y)

-Steve

On Thu, 13 Mar 2014 09:17:06 -0400, Daniel Murphy <yebbliesnospam@gmail.com> 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.

Are they using assumeSafeAppend? If not, totally understand. If they are, then I want to fix whatever is wrong.

-Steve

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

On Thu, 13 Mar 2014 09:37:51 -0400, Dicebot <public@dicebot.lv> 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

I think you might find that it will run considerably faster in that case. In the old mechanism of D1, the GC lock was used on every append, and if you had multiple threads appending simultaneously, they were contending with the single element cache to look up block info. Appender only needs to look up GC block info when it needs more memory from the GC.

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.

-Steve

On Thu, 13 Mar 2014 09:37:51 -0400, Dicebot <public@dicebot.lv> 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

Also, if you didn't see my other message, assumeSafeAppend would help here. I would replace all arr.length = 0 to a function call that does arr.length = 0; arr.assumeSafeAppend();

-Steve

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

"Dicebot"  wrote in message news:pwgfmyizziqoqhwrbtdf@forum.dlang.org...

> 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

Or stick in assumeSafeAppend everywhere?  You can even do this before the transition, with a no-op function.