On Mon, Jul 29, 2013 at 7:21 PM, Thiez wrote:
> This would make for some interesting/confusing calling conventions. It would
> also mean &T and &mut T would no longer share a representation; &int would
> simply be int, but &mut int would still have to be a pointer.
Yes.
> Borrowing &mut T to &T
On Mon, Jul 29, 2013 at 1:21 PM, Thiez wrote:
> This would make for some interesting/confusing calling conventions. It would
> also mean &T and &mut T would no longer share a representation; &int would
> simply be int, but &mut int would still have to be a pointer. Borrowing &mut
> T to &T would b
This would make for some interesting/confusing calling conventions. It
would also mean &T and &mut T would no longer share a representation; &int
would simply be int, but &mut int would still have to be a pointer.
Borrowing &mut T to &T would be a dereference if T is pointer size or
smaller? The on
On Sun, Jul 28, 2013 at 11:54 PM, Daniel Micay wrote:
> On Sun, Jul 28, 2013 at 4:54 PM, Brian Anderson wrote:
>> FWIW I prefer the terms box and reference. I don't really understand the
>> idea that only * is 'semantically a pointer' though.
>
> Unique boxes can be implemented without a pointer
Hi,
On 28/07/2013 18:46, Patrick Walton wrote:
It's not that complicated. Most of the hard work is in placement new.
And it's not like we have a choice really: Servo is starting to grow
custom smart pointers all over the place (the DOM, probably the Flow
tree, all JS objects, ARC, RWARC...) Mak
On Sun, Jul 28, 2013 at 4:54 PM, Brian Anderson wrote:
> On 07/28/2013 01:17 PM, Gábor Lehel wrote:
>>
>> On Sun, Jul 28, 2013 at 7:42 PM, Daniel Micay
>> wrote:
>>>
>>> On Sun, Jul 28, 2013 at 12:50 PM, Patrick Walton
>>> wrote:
I'm as sympathetic as anybody to want to reduce the numb
On Sun, Jul 28, 2013 at 3:34 AM, Erick Tryzelaar
wrote:
> Hey Gábor!
>
> This is a neat observation!
Thanks.
> I especially like how Option<&T> represents
> nullable pointers. However, I am not sure if a bottom region as you
> described quite captures the right semantics. While it's neat how it
On 07/28/2013 01:17 PM, Gábor Lehel wrote:
On Sun, Jul 28, 2013 at 7:42 PM, Daniel Micay wrote:
On Sun, Jul 28, 2013 at 12:50 PM, Patrick Walton wrote:
I'm as sympathetic as anybody to want to reduce the number of pointer types
in the language, as it's folks' #1 complaint about Rust. But I th
On Sun, Jul 28, 2013 at 7:42 PM, Daniel Micay wrote:
>
> On Sun, Jul 28, 2013 at 12:50 PM, Patrick Walton wrote:
> >
> > I'm as sympathetic as anybody to want to reduce the number of pointer types
> > in the language, as it's folks' #1 complaint about Rust. But I think this
> > one is probably a
I've found the short circuit in my brain: the problem is that an (in
hindsight embarrassingly obvious) invariant of `&'a T` is that it's
outlived by whatever it's pointing at, which is what has the lifetime (at
least) 'a. So if 'unsafe is the empty lifetime, then `&'unsafe T` is an
oxymoron: it can
On Sun, Jul 28, 2013 at 12:50 PM, Patrick Walton wrote:
>
> I'm as sympathetic as anybody to want to reduce the number of pointer types
> in the language, as it's folks' #1 complaint about Rust. But I think this
> one is probably a necessary evil.
>
>
> Patrick
We can reduce the number of pointer
On 7/27/13 7:51 AM, Gábor Lehel wrote:
Thoughts?
Niko and I discussed and debated this exact proposal a few months ago :)
The outcome was that it wasn't worth it for a few reasons:
* The FFI really wants sweet syntax for C pointers.
* `'unsafe` isn't really a region, as it doesn't fit in th
On 7/28/13 4:00 AM, Armin Ronacher wrote:
Hi,
On 28/07/2013 11:13, Huon Wilson wrote:
As I understand it, this is planned[1] as part of the
move-GC-to-the-libraries proposal[2]: that is, provide some traits with
lang-items (like Eq, Add, Drop, etc.) which, for example, give library
pointers the
Hi,
On 28/07/2013 11:13, Huon Wilson wrote:
As I understand it, this is planned[1] as part of the
move-GC-to-the-libraries proposal[2]: that is, provide some traits with
lang-items (like Eq, Add, Drop, etc.) which, for example, give library
pointers the ability to be auto-borrowed to &.
This how
On 28/07/13 18:57, Armin Ronacher wrote:
It would be a different thing if we could build things like
std::shared_ptr and overload all operators and it integrates well
into the rest of the language, but Rust is not built with that in mind.
As I understand it, this is planned[1] as part of the
Hi,
On 28/07/2013 03:34, Erick Tryzelaar wrote:
That said, I still think there is a good argument about whether or not
we need unsafe pointers in the library or in the language. bstrie
brought up this idea of moving *T out of the language and into a
library, as in an Unsafe or RawPtr type.
Right
Hey Gábor!
This is a neat observation! I especially like how Option<&T> represents
nullable pointers. However, I am not sure if a bottom region as you
described quite captures the right semantics. While it's neat how it falls
out naturally that you need to use an unsafe block to dereference a
`&'u
Some discussion has sprouted on reddit:
http://www.reddit.com/r/rust/comments/1j5vbn/rustdev_rfc_removing_t/
On Sat, Jul 27, 2013 at 4:51 PM, Gábor Lehel wrote:
> Spurred by https://github.com/mozilla/rust/issues/7694 I was thinking
> about the differences between `*` and `&` and the reason both
Spurred by https://github.com/mozilla/rust/issues/7694 I was thinking about
the differences between `*` and `&` and the reason both need to exist.
As far as I can tell the differences boil down to:
- The compiler makes no attempt to enforce any invariants for `*T`
Meaning that, in an interesti
19 matches
Mail list logo
