On 5/11/2014 8:54 AM, Timon Gehr wrote:
It is not an escape from ARC per se. It is a way to write type safe code which
is not dependent on the allocation strategy of the processed data. (One can e.g.
safely borrow mutable data as immutable and the type system ensures that during
the time of the borrow, the data does not mutate.)
That's clearly an additional benefit of the borrowed pointer notion. But have
you examined generated Rust code for the cost of inc/dec? I haven't, but I don't
see any way they could avoid this (very expensive) cost without borrowed pointers.
The type system tracks lifetimes across function and data structure boundaries.
The main restriction is that such a pointer cannot be escaped. (But borrowed
pointers may still be stored in data structures.)
The idea must be that the borrowed pointer lifetime cannot exceed the lifetime
of the lender.
The thing is, if the compiler is capable of figuring out these lifetimes by
examining the code, then there would be no need for the programmer to specify a
pointer as borrowed - the compiler could infer it. Hence, there have got to be
significant restrictions to the point where the compiler could figure out the rest.
2. Introducing an annotation to distinguish a borrowed pointer from an
ARC pointer. If you don't use the annotation, you get pervasive ARC with
all the poor performance that entails.
...
No, this is completely inaccurate: Both choices are explicit,
Yes, one is & and the other is @. This does not change my point. Back in the bad
old DOS days, there was near* and *. The choices were explicit, but the results
were there anyway - people overwhelmingly chose the more general *, performance
be damned.
and reference
counting is just one of the possible memory management schemes. (Hence borrowed
pointers are used unless there is a reason not to.)
Yes, I can see it supports other schemes, but I predict that RC will dominate,
and other schemes will be about as pervasive as using Boehm's GC with C++.
Implicit in borrowed pointers is Rust did not solve the problem of
having the compiler eliminate unnecessary inc/dec.
Avoiding inc/dec is not what justifies borrowed pointers.
I find that very hard to believe. It implies that there is little cost to
inc/dec, or the compiler is clever enough to eliminate the bulk of the inc/dec
pairs.
My experience with pointer annotations to improve performance is pretty
compelling - almost nobody adds those annotations. They get their code
to work with the default, and never get around to annotating it.
The 'default' way to pass by reference is by borrowed pointer.
Time will tell how well having the most restrictive pointer type be the default
works out.
They do not mix. A function taking one type of
pointer cannot be called with the other type.
A function taking a borrowed pointer can be called with a reference counted
pointer. Abstracting over allocation strategy is the point of borrowing.
Right, and a function in DOS taking a * would accept a near*. But the other way
did not work, and so people wrote their functions using *, performance was
thrown under the bus.
Are these valid concerns with Rust?
I don't think they are.
Perhaps you're right. But my experience with DOS programming is programmers
preferred convenience and reusable functions, and hence used plain * everywhere.
And like I said, this provided a huge competitive advantage for me.
The great boon with 32 bit code was the elimination of special pointer types,
now it was easy to write fast, reusable functions, and the effort involved in
creating efficient data structures dropped by probably half.
It seems clear that the decisions of borrow/managed are going to pervade Rust
code. How well is that going to work with complex programs and data structures?
How well with average programmers? How well is it going to work when some leaf
has to change from borrowed to managed, and the ripple effects of that change?
These are all unknowns, not proven successful technology. My experience with a
similar system (16 bit C) does not make it look promising, as far as performance
goes.
