Swift deprecate i++ and c-style for loop

[Jonathan M Davis via Digitalmars-d]

On Thursday, 25 February 2016 at 19:03:12 UTC, Steven 
Schveighoffer wrote:
> On 2/24/16 3:47 PM, Ola Fosheim Grøstad wrote:
>> On Wednesday, 24 February 2016 at 18:06:19 UTC, Steven 
>> Schveighoffer wrote:
>>> I'm quite glad D stuck with the same type for arrays and 
>>> array slices.
>>
>> And how will you get around this when not having a GC?
>>
>
> I don't follow. D's arrays will always have a GC.
>
> If you have a different type of array, it's a different type, 
> it can do whatever it wants.

Remember that a dynamic array does not necessarily refer to 
GC-allocated memory. The dynamic array operations don't care 
about that at all, but it does make it so that you can have a 
problem figuring out when it's okay to free the memory that you 
sliced them from if you start passing them around all over the 
place and potentially storing them. So, in that regard, the fact 
that a dynamic array doesn't really own or manage its own memory 
can complicate things when the dynamic array was not allocated 
via the GC (be it because it was sliced from malloced memory or 
sliced from a static array or whatever).

There's also the issue that some folks disable the GC, which 
doesn't prevent dynamic arrays from working aside from the few 
operations that require the GC, but it does mean that you to be 
that much more careful about how you use them.

Personally, I think that using malloc or a static array to back a 
dynamic array works great if you're dealing with localized stuff 
that you're going to pass to pure, free functions (which 
therefore can't slice the dynamic array and store it elsewhere), 
but once you're dealing with dynamic arrays that get passed 
around and stored arbitrarily, it gets seriously iffy to slice 
malloced memory or static arrays and start passing those dynamic 
arrays around. It quickly becomes far more sensible to create a 
container that gives you range rather than deal with dynamic 
arrays.

- Jonathan M Davis