libmobile VS rfcs

The "switch" method isn't too uncommon, but usually people have an init function and "state" pointer that's passed into the coroutine function. I've used this method a lot in embedded projects, where one coroutine was handling motor acceleration/deceleration while the other would simply tell it what direction to go, but I've also used it for networked libraries[1].

You don't really need to introduce macro hell for it to be manageable, though I've never found reading switch/case flow to be very enjoyable.

[1]: https://github.com/REONTeam/libmobile/blob/master/relay.c#L3...

> > no dynamic linking

> There is.

Eh, I'm a Rust fan, and I hate the dynamic linking situation too.

I genuinely cannot see how Rust would be able to scale to something usable for all system applications the way it is now. Is every graphical application supposed to duplicate and statically link the entire set of GNOME/GTK or KDE/Qt libraries it needs? The system would become ginormous.

The only shared library support we have now is either using the C ABI, which would make for a horrible way to use Rust dependencies, or by pinning an exact version of the Rust compiler, which makes developing for the system almost impossible.

Hopefully we'll get something with #[export] [1] and extern "crabi" [2], but until then Rust won't be able to replace many things C and C++ are used for.

[1] https://github.com/rust-lang/rfcs/pull/3435

[2] https://github.com/rust-lang/rfcs/pull/3470

As you can see, all trait methods are stored in sequence without any distinction between which method belongs to which trait. This is why upcasting is not possible. There's an ongoing RFC—RFC 2765—tracking this issue. Instead of discussing the solution proposed by the RFC here, we’ll introduce a more general workaround by adding an AsBase trait:

And for extra context the RFc lays out the current design and future options: https://github.com/rust-lang/rfcs/blob/master/text/3324-dyn-...

> so your claim is that rust compiler knows in advance which will be used by the target and adjusts its softfloat accordingly?

Rust performs FP operations using the precision of the underlying type. For compile time evaluation this is enforced by Miri, and for runtime evaluation this is enforced by carefully emitting the appropriate LLVM IR.

> IIRC there are cases for SIMD where there is only a 2 ULP guarantee and some tryhard silicon gives you 1 ULP for the same opcode.

Rust only permits operations in constant contexts when it's confident that it can make useful guarantees about their behavior. In particular, FP ops in const contexts are currently limited as follows:

"This RFC specifies the behavior of +, - (unary and binary), *, /, %, abs, copysign, mul_add, sqrt, as-casts that involve floating-point types, and all comparison operations on floating-point types."

https://github.com/rust-lang/rfcs/blob/master/text/3514-floa...

Rust doesn't support that, but there's an RFC trying to figure out how that could be done (hasn't gone anywhere after more than 10 years of discussions): https://github.com/rust-lang/rfcs/issues/294

But Rust supports macros, just like Lisp, so of course someone wrote a library that provides something similar:

https://docs.rs/some-error/latest/some_error/

Their post about how they came up with this crate is quite interesting:

https://jam1.re/blog/anonymous-sum-types-for-rust-errors

> The same pattern in Rust would just use variadic templates/generics.

Are you sure Rust has variadic generics? https://github.com/rust-lang/rfcs/issues/376

> I regret having to sacrifice API design to satisfy something of a corner case usage.

A possible future alternative would be to bound the macro in some way on Freeze, once that is stabilised. See the RFC for details: https://github.com/rust-lang/rfcs/pull/3633

This would of course be a tradeoff again, as it would disallow interior mutability then.

There is talk of making it illegal to have a reference be unaligned, or even point to very low addresses: <https://github.com/rust-lang/rfcs/pull/3204>. At one point, there was even talk of certain kinds of references not even being stored as memory addresses at all: <https://github.com/rust-lang/rfcs/pull/2040>. And Box<_> is not #[repr(transparent)] either. Only *const _ and *mut _ have a guaranteed ABI.

Just because you write fewer, but still more than zero, “unsafe” keywords does not mean your code is more safe.