Default argument values aren't language agnostic

[kastiglione]

Using an example to demonstrate the issue:

If paltrace is called while stopped in some swift code, the user would expect to be able to run paltrace someValidSwiftExpression. As such, paltrace should interpret input based on the active language at a breakpoint. However, the paltrace command has a default view of (id)[[UIApplication sharedApplication] keyWindow], but this expression would have to be evaluated as objc.

The solution that seems to strike the right balance to me is:

Remove the ability for commands to declare defaults in fb.FBCommandArgument, which would force commands to knowingly handle a default.

Other possibilities are:

1. Allow commands a way to check if an argument was provided by a default
2. Use a heuristic to recognize when a value is swift or objc
3. Use a known "keyword" for the default

The second option would be nice to have in general, and could be desirable in addition to whatever solution chosen for handling defaults.

[DerekSelander]

Another (partial) possibility to add to the table:

SBFunction has the GetLanguage() method. You can figure out which context you are from there.
Easy way to test: Break in a swift method:

(lldb) script lldb.frame.function.GetLanguage() == lldb.eLanguageTypeSwift
True

Breaking out of the blue gives you lldb.eLanguageTypeUnknown and of course there is lldb.eLanguageTypeObjC