On 2/25/15 1:58 AM, Ivan Timokhin wrote:
Oh. So, whenever you pass a reference-counted slice around, you need to do
it with the full inc/dec protocol, which, as Walter has mentioned several
times already, leads to code bloat and performance hits. So... no to
efficient reference counting? Also, no slicing of static arrays in @safe
code?
Correct.
There's an issue of perception that I just figured, which explains a lot
of the drama and trash talk about DIP25.
DIP25 is not a borrowing mechanism. Its charter is to make reference
counted structs (and a variety of other structs) usable in @safe code.
As RCSlice shows, with DIP25 a reference counted slice switches from
unusable to usable in @safe code by adding one token to an otherwise
unchanged implementation. That is Remarkable, and is Good Programming
Language Design(tm).
Borrowing data in a scoped manner is the charter of DIP69. Given the
excellent quality of DIP25, it's likely it is Here To Stay and DIP69, or
any other proposal for borrowing, will work with it (and probably
leverage it).
Andrei
