101–110 of 175 posts
Earlier quoted context omitted.
That's a conversion, not the same. The naive equivalent to transmute would be int8_t x = 2; bool y = *reinterpret_cast (&x); But reinterpret_cast isn't valid in a constexpr scope.
> But reinterpret_cast isn't valid in a constexpr scope. std::bit_cast is
Take a look at https://contextgeneric.dev , it's as close as one can get to solving this issue without modifying rustc.
No thanks. Most of the time you do not need macros and adding those is not free.
CGP enables you to write overlapping and orphan implementations of any trait, breaking free from Rust's coherence rules while maintaining type safety.
Isn't it the case that coherence is what makes Rust’s dependency graph sound? So, why would I want to give up that?
Earlier quoted context omitted.
Rust opened the door to innovation in the low-level languages space, but as long as it is already the most theoretically advanced practical language there, it will always attract the audience that actually wants to push it further. I don't know if there is a way to satisfy both audiences.
I think there is: a schism. Another language, inspired, intelligible and interoperable with Rust, but with other goals, likely ease of use or surface simplicity. In my mind it would be pretty much the same as Rust, but whenever a compile error gives you a suggestion in rustc would instead compile (and at most be a warning in this hypothetical language). Migrating from Rust to this language would be changing a single…
How would dependencies work in this schism? E.g. if serde starts using named impls, do all dependencies have to use named impls?
Take a look at https://contextgeneric.dev , it's as close as one can get to solving this issue without modifying rustc.
Highly Expressive Macros No thanks. Most of the time you do not need macros and adding those is not free. CGP enables you to write overlapping and orphan implementations of any trait, breaking free from Rust's coherence rules while maintaining type safety. I am not sure that I need this. I can't remember to run this issue in the last couple of years. Isn't it the case that coherence is what makes Rust’s dependency gr…
Read the article that comment is on, it's all about why one would want that.
Earlier quoted context omitted.
Reflection syntax (C++26 I think) has made my 30+ years-of-C++ brain melt. It's not insane, it's just ... melt-inducing.
Yeah, for me reflection and coroutines were the first changes to C++ where the implementation and use mechanics weren't immediately obvious by reading a few references. It requires a bit of proper study to wrap your head around it.
Earlier quoted context omitted.
Rust opened the door to innovation in the low-level languages space, but as long as it is already the most theoretically advanced practical language there, it will always attract the audience that actually wants to push it further. I don't know if there is a way to satisfy both audiences.
I think there is: a schism. Another language, inspired, intelligible and interoperable with Rust, but with other goals, likely ease of use or surface simplicity. In my mind it would be pretty much the same as Rust, but whenever a compile error gives you a suggestion in rustc would instead compile (and at most be a warning in this hypothetical language). Migrating from Rust to this language would be changing a single…
This isn't a new discussion it was there around the early rust days too. And IMHO coherence and orphan rules have majorly contributed to the quality of the eco system.
can you elaborate on how have they contributed to the quality of the ecosystem?
As a non Rust man, how real are the problems in this article? Does it show up in real word or is it just a edge case? I only program in C17, C++ as C with classes and C#. Anyone can give me a good read what Traits even are?
Earlier quoted context omitted.
> 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…
> 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 fin…
Second, this compiles just fine:
constexpr int ivalue = 1;
constexpr bool bvalue {ivalue};
constexpr int ivalue = 2;
constexpr bool bvalue {ivalue};