On 23/12/15 12:45 , swift-evolution-requ...@swift.org wrote:
> Date: Tue, 22 Dec 2015 21:12:08 -0800 From: Kevin Ballard
> To: Jordan Rose Message-ID:
> <1450847528.263398.474637513.2f478...@webmail.messagingengine.com>
>
> Oh that's a good point, I hadn't thought of that. It makes sense to
> k
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.
-Kevin Ballard
On Tue, Dec 22, 2015, at 07:48 PM, Jorda
> On Dec 21, 2015, at 19:47 , Kevin Ballard via swift-evolution
> 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
There’s two different issues here, as far as I can tell. (both of which the $
operator seems to be trying to solve) The first is being able to use the start
and end indices of a collection in a more concise way, so you can write
ar[$3..<$] instead of ar[(ar.startIndex+3).. On 22 Dec 2015, at 21:
It was an intentional decision for Swift's indexes to not be based on
offset indexing. In many cases (including indexing into strings)
calculating index offsets is an O(N) operation. The design of Swift's
indexes is such that you pay the cost when constructing an index, rather
than when using the i
I don’t think I am. Maybe I’m confused: the current suggestion is the addition
of a $ operator (or labelled subscripts, or another operator) to signify
“offset indexing”, yes? As in:
someCollection[$3] == someCollection[someCollection.startIndex.advancedBy(3)]
someCollection[$3..<$] ==
someColl
On Mon, Dec 21, 2015, at 08:28 PM, Donnacha Oisín Kidney wrote:
> Why not make the “forgiving” version the default? I mean, the majority of
> python-style composable slicing would be happening on arrays and array
> slices, for which there’s no performance overhead, and the forgiving version
> wo
Why not make the “forgiving” version the default? I mean, the majority of
python-style composable slicing would be happening on arrays and array slices,
for which there’s no performance overhead, and the forgiving version would seam
to suit the “safe-by-default” philosophy. I’ve seen mistakes li
On Mon, Dec 21, 2015, at 07:29 PM, Dave Abrahams wrote:
>>> Even if we need separate symbols for “start” and “end” (e.g. using
>>> “$” for both might just be too confusing for people in the end, even
>>> if it works otherwise), I still think a generalized form that allows
>>> ranges to be used ever
> On Dec 21, 2015, at 1:51 PM, Kevin Ballard wrote:
>
> On Mon, Dec 21, 2015, at 11:56 AM, Dave Abrahams wrote:
>>
>>> On Dec 19, 2015, at 8:52 PM, Kevin Ballard via swift-evolution
>>> mailto:swift-evolution@swift.org>> wrote:
>>>
>>> On Fri, Dec 18, 2015, at 02:39 PM, Dave Abrahams via sw
On Mon, Dec 21, 2015, at 11:56 AM, Dave Abrahams wrote:
>
>> On Dec 19, 2015, at 8:52 PM, Kevin Ballard via swift-evolution > evolut...@swift.org> wrote:
>>
>> On Fri, Dec 18, 2015, at 02:39 PM, Dave Abrahams via swift-
>> evolution wrote:
>>>
>>> Yes, we already have facilities to do most of what
> On Dec 19, 2015, at 8:52 PM, Kevin Ballard via swift-evolution
> wrote:
>
> On Fri, Dec 18, 2015, at 02:39 PM, Dave Abrahams via swift-evolution wrote:
>>
>> Yes, we already have facilities to do most of what Python can do here, but
>> one major problem IMO is that the “language” of slicin
On Fri, Dec 18, 2015, at 02:39 PM, Dave Abrahams via swift-evolution wrote:
>
> Yes, we already have facilities to do most of what Python can do here,
> but one major problem IMO is that the “language” of slicing is so non-
> uniform: we have [a.. Introducing “$” for this purpose could make it all
> On Dec 19, 2015, at 8:27 PM, Dennis Lysenko
> wrote:
>
> Dave, perhaps we could use "^" as an anchor point for the start index and $
> as the anchor point for the end index? It's familiar to anyone who knows a
> bit of regex, and all vim users. My main worry would be ^ is already infix
> x
Dave, perhaps we could use "^" as an anchor point for the start index and $
as the anchor point for the end index? It's familiar to anyone who knows a
bit of regex, and all vim users. My main worry would be ^ is already infix
xor operator.
On Fri, Dec 18, 2015 at 5:43 PM Paul Ossenbruggen via swif
I would like to avoid what you currently have to do for iterating a
subcontainer.
for a in container[0..container.count-4] {
// do something.
}
The slicing syntax would certainly help in these common situations. Maybe there
are easy ways that I am not aware of.
- Paul
> On Dec 18,
> On Dec 18, 2015, at 1:46 PM, Joe Groff via swift-evolution
> wrote:
>
>>
>> On Dec 18, 2015, at 4:42 AM, Amir Michail via swift-evolution
>> mailto:swift-evolution@swift.org>> wrote:
>>
>> Examples:
>>
>> >>> l=[1,2,3,4,5]
>> >>> l[-1]
>> 5
>> >>> l[-2]
>> 4
>> >>> l[2:4]
>> [3, 4]
>> >>>
Or perhaps some subscripts with parameter labels, like
extension Array {
subscript(fromEnd distance: Int) -> Element {
return self[endIndex - distance]
}
}
[0, 1, 2][fromEnd: 1] // returns 2
Jacob Bandes-Storch
On Fri, Dec 18, 2015 at 1:46 PM, Joe Groff via swift-evolution <
swi
> On Dec 18, 2015, at 4:42 AM, Amir Michail via swift-evolution
> wrote:
>
> Examples:
>
> >>> l=[1,2,3,4,5]
> >>> l[-1]
> 5
> >>> l[-2]
> 4
> >>> l[2:4]
> [3, 4]
> >>> l[2:]
> [3, 4, 5]
> >>> l[-2:]
> [4, 5]
> >>> l[:3]
> [1, 2, 3]
> >>> l[::2]
> [1, 3, 5]
> >>> l[::]
> [1, 2, 3, 4, 5]
Accep
19 matches
Mail list logo
