Swift deprecate i++ and c-style for loop

[Jonathan M Davis via Digitalmars-d]

On Wednesday, 24 February 2016 at 21:03:12 UTC, rsw0x wrote:
> On Wednesday, 24 February 2016 at 20:47:50 UTC, 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?
>
> Could you expand upon what you mean here? I have an entire D 
> project not using the GC and make use of slices everywhere.

Slicing non-GC memory so that you get dynamic arrays is fine, but 
then you have to have somewhere else managing that memory, 
whereas you don't really have to worry about it when using the 
GC, and you have to avoid array operations which would use the GC 
(appending or concatenation). So, having code that doesn't use 
the GC but does use dynamic array treat dynamic arrays the same 
way that a program that uses the GC would treat them can become 
problematic - particularly since it's trivial to have dynamic 
arrays floating around referring to some chunk of malloced memory 
without realizing that they're still around when you free that 
malloced memory.

So, yes. D's dynamic arrays work without the GC (barring the few 
operations that require the GC), but they're designed with the GC 
in mind and don't manage their own memory, meaning that you 
almost certainly need to treat them a bit differently when you 
don't have the GC (certainly, you have to be a lot more careful 
about what code you let hold onto dynamic arrays in order to 
avoid having them exist after the memory they refer to has been 
freed).

But doing stuff like feeding dynamic arrays which are slices of 
malloced memory to a bunch of functions that just process them 
and give you a result without holding onto them or attempting to 
append to them should work just fine. It's the stuff that might 
hold onto them where things get hairy.

- Jonathan M Davis