Chris Lattner

Yes he was, because it's a software problem and he's proven himself to be world class at solving software problems. Here is some more evidence from his resume.

"When I joined Tesla, it was in the midst of a hardware transition from "Hardware 1" Autopilot (based primarily on MobileEye for vision processing) to "Hardware 2", which uses an in-house designed TeslaVision stack. The team was facing many tough challenges given the nature of the transition. My primary contributions over these fast five months were:

We evolved Autopilot for HW2 from its first early release (which had few capabilities and was limited to 45mph on highways) to effectively parity with HW1, and surpassing it in some ways (e.g. silky smooth control).
This required building and shipping numerous features for HW2, including: support for local roads, Parallel Autopark, High Speed Autosteer, Summon, Lane Departure Warning, Automatic Lane Change, Low Speed AEB, Full Speed Autosteer, Pedal Misapplication Mitigation, Auto High Beams, Side Collision Avoidance, Full Speed AEB, Perpendicular Autopark, and 'silky smooth' performance.
This was done by shipping a total of 7 major feature releases, as well as numerous minor releases to support factory, service, and other narrow markets.
One of Tesla's huge advantages in the autonomous driving space is that it has tens of thousands of cars already on the road. We built infrastructure to take advantage of this, allowing the collection of image and video data from this…

To be clear, the compiler is not forbidden from optimizing `always_returns_true` to unconditionally return true. After all, undefined behavior can cause anything to happen, and that includes returning true. Normally LLVM would perform exactly that optimization. But in this case `always_returns_true` is inlined first, so it becomes something like `undef < 150 || undef > 120`; LLVM propagates the `undef` outward through the expression until the whole condition is `undef`, and then it arbitrarily picks that the condition should be false.

But `always_returns_true` is not an example of how this particular undefined behavior can be useful as an optimization, merely an example of how it can be dangerous. For some examples of how it can be useful:

- Document describing the origins of `undef` in LLVM: http://nondot.org/sabre/LLVMNotes/UndefinedValue.txt

Basically, it helps to be able to replace "cond ? some_value : undef" with "some_value", especially when the code has been transformed to SSA form.

- Some architectures literally have a 257th possible value, like Itanium [1] [2]. On Itanium, every register can be set to "Not a Thing", i.e. uninitialized, and the CPU will trap if you try to store such a value to memory. Ironically, NaT was created in order to make the CPU's behavior more defined in a certain case, or at least more predictable... argh, I'm too tired to explain it properly; look at section 2.3.1 of [2] for a somewhat confusing explanation.

[1]…

I read the transcript but at the end I wished they had touched upon some comparisons of Swift with C# and the open sourcing of the .NET platform by Microsoft. Craig's/Apple's comments on that would be interesting now that C# and .NET are also becoming truly cross platform (unlike the Mono platform that lagged behind), which is something Swift also aims to be, although we don't know what frameworks and libraries from Apple would or could become cross platform.

Also, C# and .NET have had longer than a decade to become what they are today. It would've been interesting to hear more details on what lessons and developments from the last decade and a half helped accelerate the development of Swift (not just from C#.NET, but also other languages and programming paradigms).

Chris Lattner's page [0] just mentions a one liner saying "...it also greatly benefited from the experiences hard-won by many other languages in the field, drawing ideas from Objective-C, Rust, Haskell, Ruby, Python, C#, CLU, and far too many others to list."

A geeky interview with Chris Lattner might be the next thing to look forward to on this topic. :)

[0]: http://nondot.org/sabre/

> I don't see any Python influence in Go

Well, in Google's own words[1]: "Go attempts to combine the development speed of working in a dynamic language like Python with the performance and safety of a compiled language like C or C++". Some go datastructures are very python-like. Coming from a big Python shop, it's unsurprising.

Chris Lattner mentions Python[2] as an influence among others. Swift's lists and dicts are very python-like. The way python deals with datastructures is one of its strong points, and it's clearly more modern than anything C-like.

Both Go and Swift are more restrictive than Python in many ways, mostly for performance reasons since they are built for specific needs, but the influence is there and openly admitted.

[1] https://techcrunch.com/2009/11/10/google-go-language/

[2] http://nondot.org/sabre/

"I started work on the Swift Programming Language (wikipedia) in July of 2010. I implemented much of the basic language structure, with only a few people knowing of its existence. A few other (amazing) people started contributing in earnest late in 2011, and it became a major focus for the Apple Developer Tools group in July 2013.
The Swift language is the product of tireless effort from a team of language experts, documentation gurus, compiler optimization ninjas, and an incredibly important internal dogfooding group who provided feedback to help refine and battle-test ideas. Of course, it also greatly benefited from the experiences hard-won by many other languages in the field, drawing ideas from Objective-C, Rust, Haskell, Ruby, Python, C#, CLU, and far too many others to list."

- Chris Lattner, http://nondot.org/sabre/

Your timeline is way off.

llvm-gcc was introduced with Xcode 3.1, and clang/llvm in xcode 3.2. It targeted 10.5. This was well prior to 2011 , and seeded well before it was released. Again, you don't have to believe me, Chris's resume shows this:

http://nondot.org/sabre/Resume.html#Apple

"In this time period, my group expanded use of LLVM within Apple, supported new clients, built new features, and extended LLVM in many ways. We shipped llvm-gcc 4.2 in the Xcode 3.1 and major improvements for it in the Xcode 3.1.1 release."

That time period was in 2006-2008.

Apple made a decision that it was going to move if it could meet certain performance goals in the 2006/2007 time frame.

GPLv3 was not released until June of 2007.

In any case, this argument is pointless, you can just ask Chris why they moved.