[swift-dev] Implementation of swift's value types

[Johannes Neubauer]

Hi Arnold,

Thank you and atrick at apple.com very much for your answers. That helps already a lot. Are you Arnold from the WWDC Video? I removed all the answers that are clear and have some follow-up questions inline.

> Am 14.07.2016 um 23:02 schrieb Arnold Schwaighofer <aschwaighofer at apple.com>:
> 
>> 3. Then Arnold says that four existential containers pointing to the same value (greater than the value buffer) use 4 heap allocations. He proposes copy-on-write (using a local storage class), but **does he mean this should be implemented by hand or is this an optimization that the swift compiler does on its own?**
> 
> No the swift compiler does not do this on its own.

Are there corresponding plans? Storing „big“ values (using some statistics to evaluate where the break-even is) as reference types always, storing them in a big table per type (each value occurs only once) should be possible, right? Is this something I should post on the swift-evolution mailing list?

> 
>> The issue here is, that the switch between "swift subscript" for showing an abstraction of internals and real swift code that one should write is sometimes not clear.
> 
> Sorry about this.

This was meant as positive criticism. I really like the video!

> 
>> Doing this by hand has some clear disadvantages as this would add a reference to each usage of `Line` (and reference counting) even in the first examples of Kyle.
> 
> Yes, it is a tradeoff. Either, in the type erased context (as an instance of protocol value) copies are expensive for large value types and in the non generic/existential concrete context it is fast.

Is it really fast in the latter context for „big“ values? All collection types use copy-on-write. Especially if you have a lot of reference type properties copying seems to be slow even in the latter context. And since all collection types (including String) are backed by a reference type, even properties of these type incur additional reference counting.

> Or you make the type have indirect storage with copy on write to preserve value semantics and then you have an overhead for reference counting.
> 
> You can get the best of both worlds if you write a wrapper.
> 
> All of this comes at the cost of a lot of boiler plate code and discussions are taking place how-to improve this situation.

Are there already proposals available or is it still in early discussions? Can you give me a hint where to find more about it?

> 
>> 6. Is the Value-Witness-Table a (kind of) dictionary for all values of a given value type (bigger than the value buffer), so that you do not store any value twice on the heap, but share the reference? If this is the case the answer of *3.* should be *automatically*. But then again, the "manual" implementation of `String` and `Array` (see *4.*) make no sense anymore, does it? Or are `Array` and `String` implemented only on the lower-level and the copy-on-write implementation is not visible in their Swift implementation?
> 
> 
> I don’t full understand the question.
> 
> The value-witness-table exists per type and contains functions that describe how to copy, allocate, and deallocate values of that type.

OK. I am still a little bit unsure what it is now. Andrew Trick says:

> A value witness table is a dictionary for all values of a type regardless of whether it fits in a buffer.
> The keys are operations that can be done to any value (copy/destroy), the implementation for
> that type knows where the value is stored.

In the example Arnold (you?) used the value witness table to copy the value (see slide 171 last line of code):

```swift
pwt.draw(vwt.projectBuffer(&local))
```

Since I didn’t know that the „storage“-trick is done manually, I thought there is a (hash)table/dictionary of all values of a „big“ value type where each value is uniquely stored (constant time access). For „small“ values it would just point, to the concrete value of this very value. As mentioned above: should I post this on the swift-evolution mailing list?

All the best
Johannes

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160715/27d8ce03/attachment.sig>