This would also mean that you wouldn't need unsafe{} to call into the Fil-C ffi. The majority of unsafe{} in (non pure-rust) cargo dependencies is calling C ffi. Rust + Fil-C is a great match that fills a particular niche, I'd love to see it happen.

▲

inigyou 3 days ago | parent [-]

How does it prevent multiple mutable pointers?

▲

aw1621107 3 days ago | parent [-]

Multiple mutable pointers are fine. You need to be careful to ensure you don't turn them into multiple coexisting mutable references, though.

▲

inigyou 2 days ago | parent [-]

Nice pedantry. How does it prevent multiple coexisting mutable references?

	▲	BobbyTables2 2 days ago \| parent \| next [-]
		It’s not pedantry. Pointers and references are truly different things. A normal C compiler actually has to worry about a lot of extreme cases. Imagine a function takes two pointer arguments. What if they point to the same thing? What if one points to the other and is used for a write? The nature of the code generated varies greatly if these are possibilities…
	▲	aw1621107 2 days ago \| parent \| prev [-]
		I'm not sure you need to? Rust references don't exist in C, after all. That being said I wouldn't be surprised if there were other factors that would weigh against considering FFI calls to Fil-C safe by default (e.g., Fil-C's somewhat looser bounds on what is considered a valid pointer access).