I described that radar rather poorly. If you look at what I described in the radar, I basically want them to ship the swift compiler as part of the core OS, and an eval function would compile its argument and load it into the current process using the dynamic linker. I definitely do not want interpreted Swift.

Swift is certainly a language that relies on compiler optimizations. I don't want to change that.

But it would be unable to interact in a symbolic way with the calling app. It might be able to access things in frameworks but it might as well be a separate app that you compile with external tools at that point.

As to why it couldn't interact with the running app others have given some examples but it couldn't even reliably call functions as they may be inlined or generics may only be compiled into their required type specific versions.

I do expect[0] Apple to open source Swift when it is finally released and it to be part of the LLVM project so you could embed whatever parts make sense in your own applications but it wouldn't be like an eval function as I understand it although you could probably use it to make your own playground system. Basically it would be an LLVM feature/library not a Swift language feature.

[0] Guess. I have no inside information and may end up disappointed.

Eval is not a good idea because programmers inevitably have trouble with "Little Bobby Tables"[1].

There is a place for eval. Just not in a language which is going to be used on Grandma's devices.

[1] http://xkcd.com/327/

It would allow for rapid prototyping perhaps

Can you give me an example of what you would expect it to do that can't be done in the Playground and how you would use it?

It strikes me as quite an expensive[0] change to make just to support slightly different development models.

[0] Potentially requiring different code generation mode embedding type information and other run-time information that wouldn't generally be used and then having a system that can use the information to execute arbitrary code. It might be that much of this is already need for other purposes but I wouldn't assume so without information.

Using Injection for XCode gives you live coding close to a Smalltalk system. So you live code on your actual app, super nice for tuning core image filters, or any thing where small iterations are needed between compiles. I literally save hours in a day by not needing a "recompile, relaunch, find my context, repeat" loop.

I think the intention is that Playgrounds will cover this use case but I can see where the set up is the result of complex and disparate code it might be hard to pull into the Playground and repl in the code is helpful. I do it myself in LLDB and use Pry when working with Ruby/Rails to dig into the state at the context and try things out. I can see this working with a debug build with LLVM/LLDB support.

The OP seemed to be picturing a service that could operate in released software and I find that harder to imagine.

Code injection for swift would be great, but there is no reason it would have to be done using either eval or message passing. The debug symbols are enough for the compiler to do hot code replacement, either directly or through trampolines.

I highly doubt it will happen. Apple wants to avoid runtime compilation (which this would be an LLVM runtime deal I assume) on iOS from what I gather about their no-VM-on-iOS policy.

Not sure if Apple embeds typing metadata in libraries. If so, I don't see why type checking is impossible, at least for exposed (i.e. @objc) stuff.