5 ms·
What exactly would a third party developer do with good documentation for the Swift ABI? The only practical application I can think of would be implementing som
by gok 7y ago
What exactly would a third party developer do with good documentation for the Swift ABI? The only practical application I can think of would be implementing some kind of Swift FFI, which has a realistic target market of fewer than 10 developers. And in practice, they would probably just use the Swift source code instead.
- saagarjha 7y agoFunction hooking is a lot more popular than you think it is.
- pjmlp 7y agoAnd usually forbidden in modern sandboxing.
- saagarjha 7y agoSandboxing has almost nothing to do with (and does not prevent) function hooking.
- pjmlp 7y agoTrue, they are orthogonal. However Windows, xOS and Android sandboxing are relatively restrictive in that use case.
- saagarjha 7y agoHow so? With dynamic linking function hooking is not all that difficult.
- pjmlp 7y agoFor the stuff that comes with your own package sure, but don't expect to override all the OS libraries without eventually get the process killed, like trying to use DLL injection and OS Hooks on Windows.
- gok 7y agoSeems like that really depends more on calling conventions than an ABI overall?
- saagarjha 7y agoCalling conventions are part of the ABI, no?
- ckok 7y agoWell considering the future of apis on osx and iOS is swift, any language that wants to target those needs to be able to talk to swift in the future. My compiler can do basic interop with swift now, but it's pretty much undocumented, unsupported, and when asking for any info the best I got, we're welcome for contributions on the docs. The docs that do exist are out of date and incomplete.