undefined | Better HN

0 pointsjandrewrogers2d ago0 comments

> starting playing around with std::launder and std::byte and strict aliasing rules and lifetime rules, and you'll yearn for the simplicity of Rust

Annotations like std::launder, lifetime manipulation, etc solve a class of problems that exist in every systems language. They inform the compiler of properties that cannot be known by analyzing the code. Rust isn't special in this regard, it has the same issues.

Without these features, we either relied on unofficial compiler-specific behavior or used unnecessarily conservative code that was safe but slower.

0 comments

tialaramex2d ago

> Rust isn't special in this regard, it has the same issues.

This is both fundamentally true and misleading. Rust has to solve the same issues but isn't obliged to make all the same bad choices to do that and so the results are much better.

For example C++ dare not perform compile time transmutations so, it just forbids them and a whole bunch of extra stuff landed to work around that, but in Rust they're actually fine and so you can just:

    const FOO: bool = unsafe { core::mem::transmute::<i8, bool>(2) };

That blows up at compile time because we claimed the bit pattern for the integer 2 is a valid boolean and it isn't. If we choose instead 0 (or 1) this works and we get the expected false (or true) boolean instead of a compiler diagnostic.

C++ could allow this but it doesn't, rather than figure out all the tricky edge cases they just said no, use this other new thing we made.

jandrewrogersOP2d ago

> For example C++ dare not perform compile time transmutations

I am confused by this assertion. You can abuse the hell out of transformations in a constexpr context. The gap between what is possible at compile-time and run-time became vanishingly small a while ago.

I think your example is not illustrative in any case. Many C++ code bases work exactly like your example, enforced at compile-time. That this can be an issue is a hangover from retaining compatibility with C-style code which conflates comparison operators and cast operators. It is a choice.

C++ can enforce many type constraints beyond this at compile-time that Rust cannot, with zero effort or explicit type creation. No one should be passing ints around.

gpderetta2d ago

First of all mem::transmute is like bit_cast (which works perfectly fine in constexpr context), not reinterpret cast.

Second, this compiles just fine:

   constexpr int ivalue = 1;
   constexpr bool bvalue {ivalue};

This fails at compile time (invalid narrowing):

    constexpr int ivalue = 2;
    constexpr bool bvalue {ivalue};

Note we don't need bit_cast for this example as int to bool conversions are allowed in C++.

tialaramex2d ago

Surely "We have many different ways to do this, each with different rules" is exactly the point? C++ 20's std::bit_cast isn't necessarily constexpr by the way although it is for the trivial byte <-> boolean transmutation I mentioned here.

I see that C++ people were more comfortable with the "We have far too many ways to initialize things" examples of this problem but I think transmutation hits harder precisely because it sneaks up on you.

1 more reply

germandiago2d ago

In my experience conversions is one of the things that maximum warning levels do excellent static analysis for nowadays. In the last 15 years I hardly had a couole problems (init vs paren initialization). All narrowing etc. is caught out of the box with warnings.

poppadom19822d ago

I'm not sure what you're getting at but

const bool z = (const bool)((int8_t)2);

Is perfectly valid C++.

debugnik2d ago

That's a conversion, not the same. The naive equivalent to transmute would be

    int8_t x = 2;
    bool y = *reinterpret_cast<bool *>(&x);

But reinterpret_cast isn't valid in a constexpr scope.

2 more replies

j / k navigate · click thread line to collapse

0 comments

tialaramex2d ago

> Rust isn't special in this regard, it has the same issues.

This is both fundamentally true and misleading. Rust has to solve the same issues but isn't obliged to make all the same bad choices to do that and so the results are much better.

    const FOO: bool = unsafe { core::mem::transmute::<i8, bool>(2) };

C++ could allow this but it doesn't, rather than figure out all the tricky edge cases they just said no, use this other new thing we made.

jandrewrogersOP2d ago

> For example C++ dare not perform compile time transmutations

C++ can enforce many type constraints beyond this at compile-time that Rust cannot, with zero effort or explicit type creation. No one should be passing ints around.

gpderetta2d ago

First of all mem::transmute is like bit_cast (which works perfectly fine in constexpr context), not reinterpret cast.

Second, this compiles just fine:

   constexpr int ivalue = 1;
   constexpr bool bvalue {ivalue};

This fails at compile time (invalid narrowing):

    constexpr int ivalue = 2;
    constexpr bool bvalue {ivalue};

Note we don't need bit_cast for this example as int to bool conversions are allowed in C++.

tialaramex2d ago

1 more reply

germandiago2d ago

poppadom19822d ago

I'm not sure what you're getting at but

const bool z = (const bool)((int8_t)2);

Is perfectly valid C++.

debugnik2d ago

That's a conversion, not the same. The naive equivalent to transmute would be

    int8_t x = 2;
    bool y = *reinterpret_cast<bool *>(&x);

But reinterpret_cast isn't valid in a constexpr scope.

2 more replies

j / k navigate · click thread line to collapse