On 23/12/15 12:45 , [email protected] wrote: > Date: Tue, 22 Dec 2015 21:12:08 -0800 From: Kevin Ballard > <[email protected]> To: Jordan Rose <[email protected]> Message-ID: > <[email protected]> > > 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 >>>>> <[email protected]> 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.
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 <[email protected]> Belo Horizonte, Brazil "In the affairs of others even fools are wise In their own business even sages err." http://brockerhoff.net/blog/ _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
