No, it is not, as has been covered extensively. Atomic operations in Fil-C tear.
// global
foo* p = initial();
// Thread 1
p = something_else();
// Thread 2
p[attacker_controlled_index] = value;
There are interleavings in which p has the value of initial() but the capability of something_else(), or vice versa, which means that an attacker who can perform memory access with an offset into p can access the wrong object through p. This is a violation of memory safety as commonly understood.
But sure, you can just bleat Pizlo's claims of safety instead of engaging with the substance of his runtime model. The point is that Fil-C does not provide full memory safety, and cannot until it updates pointer and capability atomically, and it can't do that without paying much more for general memory access than it does today.
Sure. Or use a mutex, or use any of the other zillion concurrency-safe constructs out there. Still, Fil-C is memory-safe only up to data-race freedom. This bound is still a plenty useful, but Pizlo shouldn't be going around saying Fil-C is memory-safe in general when it ain't.
But sure, you can just bleat Pizlo's claims of safety instead of engaging with the substance of his runtime model. The point is that Fil-C does not provide full memory safety, and cannot until it updates pointer and capability atomically, and it can't do that without paying much more for general memory access than it does today.