Attachment: Download

Issue Description:

Swift's REPL is a terrific idea, and should be a terrific tool for exploratory coding where playgrounds are not suitable [1]. Unfortunately, while the /usr/bin/swift REPL works perfectly well for "toy programming", where each line returns simple values (booleans, numbers, strings), it is an unmitigated UX disaster when working with more complex objects, especially struct/class instances containing large amounts of private state (e.g. internal lookup tables).

Please see attached screenshots: one of the Python3 REPL, and one of the Swift REPL running the equivalent code [2]. The Python REPL displays a value's debug description string, allowing the value to supply its literal representation or other programmer-friendly representation for display. The Swift REPL dumps a complete inspection of the object, which for any non-trivial object (e.g. array, dictionary) is at best human-unfriendly but at least nominally readable, but rapidly degrades to hundreds or thousands of hideously incomprehensible line noise for more complex struct or class instances.

The solution would be for the REPL to display the returned value's debug description string by default (or description string if `debugDescription` is not implemented), and only display a full object inspection if/when the user explicitly requests it. Adding an `:inspect [ VARNAME ]` command would provide a handy shortcut here to save the user having to jump in and out of debugger mode, but this is not essential and is secondary to the main task of making the standard "Print" behavior not suck.

–
[1] Playgrounds' need to recompile and rerun the entire 'script' after each change makes them highly unsafe and/or frustrating for any task that includes side-effectful or time-consuming operations. The CLI REPL avoids these problems by executing each line once in a persistent environment. (One can argue, of course, that Playgrounds have no excuse not to use a persistent environment too—heck, even AppleScript can do this—but that is a ticket for another time and place.)

[2] The Python example uses the `appscript` (Apple event bridge) library (https://pypi.python.org/pypi/appscript/1.0.1). The Swift example uses the `SwiftAutomation` framework (https://bitbucket.org/hhas/swiftae). Both use large internal lookup tables to [amongst other things] generate their human-readable debug description strings❗, so provide particularly good examples of the current Swift REPL's pathological "Print" behavior, but other complex classes and libraries should have no problems inflicting similarly unpleasant output upon Swift users.