On Sat, Feb 1, 2014 at 9:46 PM, Patrick Walton <pcwal...@mozilla.com> wrote:
> On 2/1/14 6:43 PM, Daniel Micay wrote:
>>
>> On Sat, Feb 1, 2014 at 9:27 PM, Eric Reed <ecr...@cs.washington.edu>
>> wrote:
>>>
>>>
>>> I wasn't aware of mem::size_of before, but I'm rather annoyed to find out
>>> we've started adding bare A -> B functions since it breaks parametricity.
>>> I'd much rather put size_of in a trait, at which point it's just a weaker
>>> version of Any.
>>
>>
>> You do realize how widely used size_of is, right? I don't this it
>> makes sense to say we've *started* adding this stuff when being able
>> to get the size/alignment has pretty much always been there.
>
>
> `transmute()` breaks parametricity too, which is annoying to me because you
> can get C++-template-expansion-style errors in translation time ("transmute
> called on types of different sizes"). I proposed changing it to a dynamic
> runtime failure if the types had different sizes, which eliminates ad-hoc
> templates leaking into our trait system, but that met with extremely strong
> objections from pretty much everyone.
>
> PatrickThis could be restricted to `unsafe` code by making reflection features `unsafe` and mandating that safe functions must compile for types meeting the bounds. The `size_of` functionality is absolutely required to have any hope of writing smart pointers and containers in the library, without using ~T and ~[T] as the sole allocators. _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
