Swift: Challenges and Opportunity for Language and Compiler Research
Chris Lattner (PDF, tweet, Hacker News):
That said, many of the things we talked about earlier are actually powered by the LLVM JIT, including the REPL, #! scripts, Playgrounds, and the LLDB debugger. Being able to pick and choose the right compilation model for a specific use case is a strong point of LLVM.
[…]
The compiler can optimize Swift ARC better than (e.g.) a C++ compiler can optimize shared pointers, because the language model explicitly allows early destruction of objects.
[…]
Functions normally take ownership of their arguments, so that call will have to copy each element, incrementing any reference counts inside it.
By simply annotating the argument as borrowed, we can easily avoid that, letting the function decide whether it needs to copy. This annotation also makes this method correct for collections of affine types.
[…]
Async/await are effectively proven at this point and would fit well with the Swift type system and structure, we should probably just do it.
Funny how people here mention source breaking change as the main issue with the language. I think it’s because they haven’t used swift on a large codebase. The main issue once you start to work on a big project are compiler crash and compilation time.
I really don’t understand how a compiler can crash that much ( actually i’ve been coding in many client and server languages before and it’s the first time i see a compiler crashing while i code).
I completely agree. I welcome the source breaking changes because they have made the code much better. But the compiler and editor don’t feel like they’re at a 3.x level of reliability. I don’t have a large codebase.
Sidenote: I encountered lots of PDF bugs in macOS 10.12.2 trying to select and copy/paste text from this PDF.
1 Comment RSS · Twitter
[…] Swift: Challenges and Opportunity for Language and Compiler Research, Python 3.5: async and await, C# 5.0’s […]
