3 ms·

Hmm...Swift never struck me as a particularly interoperable design. Really rather the opposite. It has weird and super-specific calling conventions, requires

Hmm...Swift never struck me as a particularly interoperable design. Really rather the opposite. It has weird and super-specific calling conventions, requires mangled identifiers, is uber-static, uses Swift syntax for its "module" files etc. And it turns out... "Instead, Swift embeds a copy of clang, the C and C++ compiler," ...well gosh, you can brute force "interoperability" by simply creating the union of all the languages you "interoperate" with. https://www.youtube.com/watch?v=XqUgUgiToNs https://www.youtube.com/watch?v=XqUgUgiToNs "The F4 Phantom, America's proof to the world that with a big enough engine, even a brick can fly"

Tarq0n 3y ago
Sounds like the precursor to what Lattner is trying to do with Mojo: embed everything into a Frankenstein of a compiler and runtime. Time will tell if such a thing is maintainable.
- mpweiher 3y ago
  I think we already have fairly overwhelming evidence that it is not.
deleted 3y ago
[deleted]
pohl 3y ago
Don’t forget that this interoperability was put in place to support a specific engineering goal: to make it possible to slowly (over decades, probably) transition from 4 different languages (C, ObjC, C++, ObjC++) at every level of Apple’s stack towards a single memory-safe successor language. Would you recommend they wait for some weird Java-esque 100% Pure implementation within the compiler itself before they can begin that work? The ideal you’re suggesting is actually made more reachable by this work. One can imagine a Swift LLVM/Clang now. See: https://www.youtube.com/watch?v=lgivCGdmFrw https://www.youtube.com/watch?v=lgivCGdmFrw
- stephen_g 3y ago
  Wow, I'm only three minutes in, but it's a good talk. Among other parts of Apple's ecosystem (especially Webkit would make sense to move to Swift for memory safety), imagine if they start incrementally moving llvm/Clang over to Swift using this, that would be very interesting.
jmull 3y ago
If you want to interoperate with C and C++ and could either make people specify low-level details of the interface themselves or process C and C++ header files to do it automatically. Obviously the latter is a much better interoperability solution. Processing C and C++ header files means using a C/C++ compiler. It would hardly make sense to write a new one if there was a good one already available.
Someone 3y ago
> “Instead, Swift embeds a copy of clang, the C and C++ compiler," ...well gosh, you can brute force "interoperability" by simply creating the union of all the languages you "interoperate" with. That’s not what they do. To efficiently use C and C++ structs and classes from another language you have to know their layout and calling conventions. With C and C++, you have to run the preprocessor and (e.g. for C++ templates) large parts of the compiler to reliably do that. How else are you going to figure out what foo_t and bar_t in header files mean? If you need to run a compiler, using an existing compiler is the wise thing to do.

Tarq0n 3y ago

Sounds like the precursor to what Lattner is trying to do with Mojo: embed everything into a Frankenstein of a compiler and runtime. Time will tell if such a thing is maintainable.

mpweiher 3y ago
I think we already have fairly overwhelming evidence that it is not.

deleted 3y ago

[deleted]

pohl 3y ago

Don’t forget that this interoperability was put in place to support a specific engineering goal: to make it possible to slowly (over decades, probably) transition from 4 different languages (C, ObjC, C++, ObjC++) at every level of Apple’s stack towards a single memory-safe successor language. Would you recommend they wait for some weird Java-esque 100% Pure implementation within the compiler itself before they can begin that work? The ideal you’re suggesting is actually made more reachable by this work. One can imagine a Swift LLVM/Clang now. See: https://www.youtube.com/watch?v=lgivCGdmFrw https://www.youtube.com/watch?v=lgivCGdmFrw

stephen_g 3y ago
Wow, I'm only three minutes in, but it's a good talk. Among other parts of Apple's ecosystem (especially Webkit would make sense to move to Swift for memory safety), imagine if they start incrementally moving llvm/Clang over to Swift using this, that would be very interesting.

jmull 3y ago

If you want to interoperate with C and C++ and could either make people specify low-level details of the interface themselves or process C and C++ header files to do it automatically. Obviously the latter is a much better interoperability solution. Processing C and C++ header files means using a C/C++ compiler. It would hardly make sense to write a new one if there was a good one already available.

Someone 3y ago

> “Instead, Swift embeds a copy of clang, the C and C++ compiler," ...well gosh, you can brute force "interoperability" by simply creating the union of all the languages you "interoperate" with. That’s not what they do. To efficiently use C and C++ structs and classes from another language you have to know their layout and calling conventions. With C and C++, you have to run the preprocessor and (e.g. for C++ templates) large parts of the compiler to reliably do that. How else are you going to figure out what foo_t and bar_t in header files mean? If you need to run a compiler, using an existing compiler is the wise thing to do.