Earlier quoted context omitted.
> the zunsafe api is basically unused. One library uses it (OpenSSL) for good reasons Wait, so there are escape hatches? But… you’ve repeatedly said, many times, that there are zero escape hatches? And now here you’re saying not only that there only are escape hatches, but there’s a good reason to use them? Damn. Misrepresenting `unsafe{}` whilst saying your language is better because there are no escape hatches and…
From the second paragraph of fil-c.org: "Fil-C has no unsafe statement and only limited FFI to unsafe code." `zunsafe_call` is a weird thing to get hung up on as an "escape hatch", considering it's just a super limited form of FFI, intentionally designed so that it's only usable for OpenSSL's use case. > Misrepresenting `unsafe{}` `unsafe` lets you write Rust code that violates any reasonable definition of memory saf…
Except there is an escape hatch, by your own admission above?
> `zunsafe_call` is a weird thing to get hung up on as an "escape hatch"
from the docs:
> unsigned long zunsafe_call(const char* symbol_name, ...);
> Performs an unsafe call to Yolo-land.
That’s just a `unsafe{ func(…) }` escape hatch
> intentionally designed so that it's only usable for OpenSSL's use case.
Cool motive, still an escape-hatch =)
Do you have the backbone to update the fil-c website to correct the record, and let the person you retweeted here[1] know that the escape hatch row is incorrect?
Or… is what everyone says about you here true?