A slice can lose capacity simply by calling a function

[Meta via Digitalmars-d-learn]

On Sunday, 3 May 2015 at 15:21:17 UTC, Andrew Godfrey wrote:
>
>> I really don't think that it's an issue in general, but if you 
>> do want to
>> guarantee that nothing affects the capacity of your array, 
>> then you're going
>> to need to either wrap all access to it
>
> I agree with everything Jonathan said in both threads EXCEPT 
> that this is not an issue.
>
> The syntax "slice.capacity" gives the impression that 
> 'capacity' is a property of the slice.
>
> Such lack of consistency is a SERIOUS issue for D, especially 
> when it occurs in something as basic as an array. One other 
> place I see this problem is the semantics of utf8 strings.
>
> This is DEADLY for D adoption. Personally, I think I'll be 
> trying out Rust now, and checking back on these two issues 
> later. This makes me sad, D is so promising ... but 
> unfortunately the high standards it sets in many areas, are 
> completely undercut by such basic problems. I work on large 
> systems, and I can't imagine building a large system in this 
> state.

It is consistent if you look at it the perspective of wanting D's 
slices to have certain semantics while still being memory safe. 
It is word behavior; however, when you think about it, it is 
necessary if we want D's slices to have the semantics that they 
do while stomping memory. If you look at Go's slices, they are 
NOT memory safe; it's possible (and even easy) in Go to have the 
data in a slice change under you unexpectedly. This behavior is 
impossible in D as far as I know. Yes, Rust does statically 
guarantee this can never happen, but it also needs its complex 
ownership system to do that. So D is really a midway point 
between Go and Rust. Not unsafe, unlike Go, but with some 
slightly confusing behavior.