[swift-evolution] Proposal: Python's indexing and slicing
rainer at brockerhoff.net
Wed Dec 23 15:21:49 CST 2015
On 23/12/15 12:45 , swift-evolution-request at swift.org wrote:
> Date: Tue, 22 Dec 2015 21:12:08 -0800 From: Kevin Ballard
> <kevin at sb.org> To: Jordan Rose <jordan_rose at apple.com> Message-ID:
> <1450847528.263398.474637513.2F47800C at 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 at 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
>>> 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.
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.
Rainer Brockerhoff <rainer at brockerhoff.net>
Belo Horizonte, Brazil
"In the affairs of others even fools are wise
In their own business even sages err."
More information about the swift-evolution