On 05/03/2015 06:06 PM, Jonathan M Davis via Digitalmars-d-learn wrote:
> On Sunday, May 03, 2015 15:21:15 Andrew Godfrey via
Digitalmars-d-learn 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.
>
> I really don't see the problem. It's a natural side effect of how dynamic
> arrays work in D.
The problem is described in those two sentences of yours: The behavior
of a language construct depends on the implementation detail.
Unfortunately, it is backward. Normally, the semantics would be layed
out and then those semantics would be implemented.
It is not the case with D's dynamic arrays.
(Aside: Heck, we (at least you and I) can't even decide whether dynamic
arrays and slices are the same thing. (For the record, yes, they are the
same thing from every vantage point: They have the same semantics and
they are implemented in the same way.))
Saying that there is no problem would be contradicting yourself. These
are your quotes from the following thread:
http://forum.dlang.org/thread/mhtu1k$2it8$1...@digitalmars.com#post-mailman.597.1430448607.4581.digitalmars-d-learn:40puremagic.com
- "it seems like so few people understand it"
- "pretty much everyone has trouble with them initially"
- "I _still_ occasionally end up \"Aha!\" moments"
So, yes, this is a problem.
The problem is even worse because we can't come up with a consistent way
of describing the semantics after the fact (after how they are
implemented). The following are some of my attempts:
"sharing may terminate when the length of the slice increases"
"capacity is first-come first served"
However, they are only mostly correct, not always. And that's the part
that is frustrating the most: There is no way of "understanding" the
semantics so that one can "explain" them to at least to one's self.
> The only thing I can see that could be changed without
Please note that at least I am not interested in changing anything: I am
interested in a way of explaining the semantics. I could not find that
way yet. (I am eagerly waiting for your DConf talk to see how you make
sense of it all.)
> You'd still have to understand how D's
> dynamic arrays work to understand how the capacity for a dynamic array
> works.
I am happy that I do my part by opening threads like this one to shine
more light on what array capacity is not.
> And most code really doesn't care about the capacity of an array. If
> you profile and find that appending to an array is a hot spot in your
> program, then you dig in and use reserve or Appender or use something
other
> than a naked array, and you figure out what works best for your
particular
> use case, but for most code, it just works to use ~=. And if you're
> concerned about reallocations even before profiling, then it's trivial to
> just call reserve first or to use Appender. And unless you're doing
> something like constantly slicing and appending to each slice (which I
> expect to be a rare thing to do), you're really not going to run into
> problems.
I am sorry but that is missing the point. This issue is not only about
performance.
Note that I may not be the only programmer who writes the entire
application. Imagine that I write a function inside a library. Do I have
the *right* to append to my parameter slice? Do I have the right to
disturb my caller's slice? The answer is a resounding NO, in capital
letters. If I lose my caller's potentially precious and carefully
crafter capacity, perhaps after a call to reserve(), then I am a bad
library function.
As a programmer, I need guidelines. Here is what I have at this point:
Never append to a parameter slice.
> Sure, the semantics of D's dynamic arrays take some getting used to -
Yes, they do: I started learning D about 6 years ago. How many years
more do you reckon until I get them?
> especially if you want to understand all of their ins and outs.
Yes I do.
> But I really
> don't see why it's a big problem.
I said it before why it's a big problem: "The elements are const, the
slice is passed by value, but the [slice is affected]." The loss of
capacity itself is not a big deal. However, this behavior conflicts with
other parts of the language (as well as at least C and C++).
> For the most part, D's dynamic arrays just
> work.
I know you are not trolling but I can't take your brushing off this
issue with phares like "for the most part". That's the frigging problem!
"For the most part" is not sufficient. Unless somebody explains the
semantics in a consistent way, I will continue to try to do it myself.
(Remember: Never append to a parameter slice. Good function, good!)
>
> - Jonathan M Davis
>
Ali
