On Mon, Jul 29, 2013 at 7:21 PM, Thiez <thi...@gmail.com> 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 would be a dereference if T is pointer size or smaller? Yes. I would expect borrowing and never dereferencing is uncommon, but of course possible. > The only > reliable way of taking an address would be taking &mut because & would fail > for some types. If by "taking an address" you mean transmute::<&T, *T>(&foo), then yes. But that's the same as the next point. You could have an addressof() which returns *T directly, instead of going through &T. > Transmuting *something to &something or back would fail for > some types, unless we make transmute smarter. Yes. That's what decoupling the semantics of a type from its representation means. Unsafe code would have to be more careful. Maybe there would be special functions to deal with some things. It would mean there would be no way /at all/, for some T, to go from an &T to a *T pointing at the object it was borrowed from. You could point it at the &T, but that might have a shorter lifetime. Not clear if this would be problematic anywhere. (It would have be something like calling a C function with a pointer, where the C function not only accesses the pointer but returns or stores it (but doesn't mutate through it), for a lifetime that's shorter than the original T's lifetime but longer than the &T's.) > > I think for our sanity it would be best to let LLVM perform this kind of > magic when it figures out we won't notice the difference. (Can it?) Anyway, this wasn't meant to be a proposal. Just exploring an idea. It's fun to think about. Obviously there would be both complications and benefits. But it definitely seems like a good idea to think through what representation details should be specified on top of the observable semantics, and what should be left up to the implementation. *Reserving the right* to do this kind of thing might be worthwhile (like we already do for enums). > On Mon, Jul 29, 2013 at 4:47 PM, Gábor Lehel <illiss...@gmail.com> wrote: >> >> On Sun, Jul 28, 2013 at 11:54 PM, Daniel Micay <danielmi...@gmail.com> >> wrote: >> > On Sun, Jul 28, 2013 at 4:54 PM, Brian Anderson <bander...@mozilla.com> >> > 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 as long as the type >> > is no larger than the slot needed to contain a pointer-size object. >> > The pointer itself just isn't part of the type's contract, since >> > there's no pointer arithmetic. >> >> Hmm. Given immutability, in the absence of Cell or destructors, ditto >> for &T and @T? Do we even specify that it will be pointer-sized? >> >> Kind of amusing: you could have &&&&@@~~@@~~int with the same >> representation as int, and "dereferencing" at each level just >> transmute(self). >> >> It may look like this is only of theoretical interest, because no one >> in their right mind would pass int by pointer, but it would be a >> useful optimization for generic code - for the same reason. >> >> -- >> Your ship was destroyed in a monadic eruption. >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev@mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- Your ship was destroyed in a monadic eruption. _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
