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.
