Proposal: Python's indexing and slicing

Possibly a triviality, but using `$` as a short form of `$0` for closure
arguments, when there's only a single one, might be more concise.

···

On 23/12/15 12:45 , swift-evolution-request@swift.org wrote:

Date: Tue, 22 Dec 2015 21:12:08 -0800 From: Kevin Ballard
<kevin@sb.org> To: Jordan Rose <jordan_rose@apple.com> Message-ID:
<1450847528.263398.474637513.2F47800C@webmail.messagingengine.com>

Oh that's a good point, I hadn't thought of that. It makes sense to
keep $abc reserved for the debugger. I don't believe LLDB tries to
use a bare $ anywhere (although I could be wrong) so leaving that as
a valid identifier should be fine.

On Tue, Dec 22, 2015, at 07:48 PM, Jordan Rose wrote:

On Dec 21, 2015, at 19:47 , Kevin Ballard via swift-evolution >>>>> <swift-evolution@swift.org> wrote:

On another note, I'm tempted to say that we should use $start
and $end instead of $.start and $.end. The compiler doesn't
currently allow this, because it expects a number after the
$, but I see no reason why we can't relax that rule and allow
$start to be a valid token. The benefit of this approach is
it frees up $ to be used by third-party code (such as in the
older thread about rebinding `self` for DSLs where I
suggested that a block-based API can use $ as the parameter
name so code would say something like
`$.expect(foo).to(.equal(bar))`).

Without commenting on the rest of this thread, the current rule
is that identifiers starting with "$" are reserved for the
debugger (not counting implicit closure args). We can change that
rule, but the debugger folks won't be happy—the implicit
variables you get from the REPL, for example, should stay short.
I'm not sure if '$' itself falls under the current rule, though.

--
Rainer Brockerhoff <rainer@brockerhoff.net>
Belo Horizonte, Brazil
"In the affairs of others even fools are wise
In their own business even sages err."