On Fri, 31 May 2013 00:48:47 -0400, Peter Williams
<pwil3...@bigpond.net.au> wrote:
On 31/05/13 12:07, Steven Schveighoffer wrote:
On Thu, 30 May 2013 20:05:59 -0400, Peter Williams
<pwil3...@bigpond.net.au> wrote:
On 30/05/13 16:21, Ali Çehreli wrote:
On 05/29/2013 06:54 PM, Peter Williams wrote:
> I find the mechanism described in the article a little
disconcerting and
> it certainly needs more publicity as it's a bug in waiting for the
> unwary.
It certainly is disconcerting. Performance have played a big role in
the
current semantics of slices.
I should have added that it was the non determinism that disconcerted
me. It doesn't really affect me personally as a programmer now that I
know about it as I can just avoid it. But it blows out of the water
any hopes of having "proveably correct" non trivial code.
I think this is an overstatement. It depends heavily on what you are
doing, and most usages will be correct.
All uses have to be correct if you want "provably correct" otherwise you
just get "mostly correct".
All *your* uses have to be correct. What I meant was, you have to know
the pitfalls and avoid them. Because there are pitfalls, this doesn't
mean you can't prove correctness.
And the pitfalls are quite few.
You can achieve deterministic behavior depending on what you are looking
for. For certain, you can tell without any additional tools that an
append will not reallocate if the capacity is large enough.
That makes programming much easier, doesn't it. I'll just avoid it by
using:
a = a ~ b;
instead of:
a ~= b;
If you care nothing for performance, this certainly is a way to go.
where I think it might be an issue or is that broken too?
This is a conservative "always reallocate" methodology, it should work
just like you allocated a new array to hold a and b.
If a is frequently large, and b is frequently small, you will kill your
performance vs. a ~= b.
I toy in my mind with the idea that the difference between dynamic
arrays and slices should be that slices are read only and if you write
to them they get reallocated and promoted to dynamic array (kind of like
copy on write with hard linked files). But I'm sure that would just
create another set of problems. Also I imagine that it's already been
considered and discarded. BTW the slice "notation" could still be used
for assigning to sections of an array.
This was a proposed feature (not the copy on write, but copy on append).
It was so complex to explain that we simply didn't implement it. Instead,
we improved array appending performance and semantics.
The two largest differences between slices and proper dynamic arrays is
that a slice does not own it's viewed data (read: is not responsible for
the lifetime), and it's 'view' is passed by value.
-Steve
