flexstr VS rfcs

https://crates.io/crates/flexstr

Not sure I follow the question exactly and tbh it was like a year ago and I forget the specifics. You are welcome to look at the code, however:

https://github.com/nu11ptr/flexstr/blob/master/flexstr/src/b...

templates: https://github.com/nu11ptr/flexstr/tree/str_generics/generate

BStr Example CStr Example OsStr Example

Github | Crates.io | Docs.rs

[Github](https://github.com/nu11ptr/flexstr) | [Crates.io](https://crates.io/crates/flexstr) | [Docs.rs](https://docs.rs/flexstr/latest/flexstr/) | [Benchmarks](https://github.com/nu11ptr/flexstr/blob/master/benchmarks/README.md)

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.

Unfortunately I'm not super-familiar with developments around Polonius, so chances are what I can point you towards are the same things you found when searching. The most relevant bits appear to be the Polonius book [0] linked from the repo [1], but I don't know how up to date the book is or if there are more up-to-date resources. The RFC book [2] doesn't seem to have anything obviously about Polonius either.

[0]: https://rust-lang.github.io/polonius/

[1]: https://github.com/rust-lang/polonius

[2]: https://rust-lang.github.io/rfcs/

That nobody has gone through the effort of collating its requirements and writing an RFC after https://github.com/rust-lang/rfcs/pull/770 was closed (back in 2015).

I assume a big issue is that this is full of edge cases up the ass, and the value is somewhat limited in the sense that if you know you want durable writes you'll sync() and know you're fucked if you get an error, but close() does not guarantee a sync to disk, as the linux man page indicates:

> A successful close does not guarantee that the data has been successfully saved to disk, as the kernel uses the buffer cache to defer writes.

I never heard of "German strings" in place of the small string optimization before! And there had been way too many proposals to add such types to the standard library [1] [2] [3] [4]. My understanding is that:

1. Both `Vec` and `String` should share the same layout as part of the standard library's contract.

2. Unlike `String`, the equivalent optimization for `Vec` is more questionable especially when T might be any type. C++ standard libraries frequently do implement multiple layouts for std::string but not for std::vector for the same reason.

3. Rust never allows an implicit copying of `String` in the first place, which greatly benefits from the SSO, so the lack of SSO in Rust is less important compared to C++.

[1] https://github.com/rust-lang/rust/issues/4991

[2] https://github.com/rust-lang/rust/issues/20198

[3] https://github.com/rust-lang/rfcs/pull/2990

[4] https://github.com/rust-lang/unsafe-code-guidelines/issues/4...

nrc was poking at the problem in 2016 https://internals.rust-lang.org/t/struct-field-defaults/3412 which led to this RFC https://github.com/rust-lang/rfcs/pull/1806

It got postponed because it wasn't going to make it into Rust 2018: https://github.com/rust-lang/rfcs/pull/1806#issuecomment-327...