3 ms·
I can't agree with that. If you develop a videoplayer and you state it's pure Swift I think it's fair to assume the codecs and other core components (i.e. dsp)
by themihai 10y ago
I can't agree with that. If you develop a videoplayer and you state it's pure Swift I think it's fair to assume the codecs and other core components (i.e. dsp) of the said player are not imported C libs. How can it be pure Swift if it imports C libraries? The std library and toolchain(i.e runtime) may make an exception because these are usually portable, maintained by the language authors and invisible to the end developer so I think your libc argument is not valid.
- eridius 10y agoIf you developed the libraries yourself, then you have a point. But if you're using someone else's library, which they maintain, then it seems reasonable to say your application is pure Swift. Note that there's a difference between saying "my application is pure Swift" and "everything is pure Swift". If you're trying to make an argument about safety (as happens when people talk about writing things in Rust), then having the libraries written in that language is important. If you're just trying to say "this is a modern codebase using the latest tooling and APIs", then all that matters is the code you wrote, and not the pre-existing libraries that you link to.
- themihai 10y agoYou turn this into a blame game. If it's pure Swift then 100% of its source code should be Swift. This particular repository is mixed with C libs. From the dictionary: Pure - not mixed or adulterated with any other substance or material.
- eridius 10y agoSo, everything has to be Swift, except for the libraries that you personally have decided don't matter (such as libc)? That's not a very useful definition.