On 5/11/2014 1:59 PM, Timon Gehr wrote:
On 05/11/2014 10:05 PM, Walter Bright wrote:
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.
Sure, but performance is the additional benefit.
One constant theme in this thread, one I find baffling, is the regular dismissal
of the performance implications of inc/dec. Borrowed pointers are not necessary
to support raw pointers - this can be (and is in some systems) supported by
simply wrapping the raw pointer with a dummy reference count.
The reason for borrowed pointers is performance. Rust would be non-viable
without them.
I strongly suggest writing a snippet in [[insert your favorite proven technology
RC language here]] and disassembling the result, and have a look at what inc/dec
entails.
The thing is, if the compiler is capable of figuring out these lifetimes
by examining the code,
There are explicit lifetime annotations in function signatures.
Yes, because the compiler cannot figure it out itself, so the programmer has to
annotate.
It is simply not true that type systems are inherently restricted to checking
trivial properties. They can be made as strong as mathematical logic without
much fuss.
Again, Rust would not need borrowed pointers nor the annotations for them if
this knowledge could be deduced by the compiler. Heck, if the compiler can
deduce lifetimes accurately, you can get rid of GC and RC, and just have the
compiler insert malloc/free in the right spots.
Note that there is a Java version that does this partway, sometimes it will
replace a GC object with a stack allocated one if it is successful in deducing
that the object lifetime does not exceed the lifetime of the function.
Yes, one is & and the other is @.
No, actually currently one is & and the other is RC<T> AFAIK.
Then Rust changed again. The document I read on borrowed pointers was likely out
of date, though it had no date on it.
RC<T> is not more general. It cannot refer to stack-allocated data, for
instance.
So there is no general pointer type that has an unbounded lifetime?
Sure, borrowing is very lightweight, but ultimately what is most important is
that it solves the problem of multiple incompatible pointer types and makes the
type system more expressive as well.
Adding more pointer types makes a type system more expressive, by definition.
A function that uses none of the specific pointer capabilities is more general,
so what other choice of 'default' makes sense?
A function that doesn't have restrictions on what can be done with the pointers
passed to it. Borrowed pointers have restrictions on their usage - this is
explicitly stated in the Rust documentation.
Convenience and reusable functions means using borrowed pointers whenever
possible.
Of course. And writing fast code means making your functions fast whenever
possible!
It seems clear that the decisions of borrow/managed are going to pervade
Rust code.
But they are often obvious.
I've written a lot of ref counted code in the past, enough to know that such is
a pretty optimistic statement. Dealing with was a significant and ongoing drain
on my time, especially when the programs and data structures got more complex.
They are using Rust to write a safe and performant web browser while developing
the language.
Sure. But that browser hasn't been released yet. Consider that I've written safe
and performant code in D, but others tell me I am unique and that I cannot
expect average programmers to get it right.
I repeatedly point out to Manu that he can write performant code in D that does
not suffer from GC stalls, and he repeatedly replies that he has to work with
average programmers who are not capable of doing this.
So while I have no doubt that the Mozilla team may be very effective at using
Rust and making it shine, that may not be transferable to the larger community.
Borrowed pointers are not even superficially similar to near*. They are
compatible with everything else, because they can store data that was borrowed
from anywhere else.
As long as those pointers don't escape. Am I right in that one cannot store a
borrowed pointer into a global data structure? The similarity is that there are
one way conversions from one to the other, and one of the types is more general.
I infer from your other statements about Rust that it doesn't actually have a
general pointer type.
