Totally agreed with you guys, for me the matter question here is:<div><br></div><div>Why should we care about language details instead what the app really have to do?</div><div><br></div><div>Keeping in mind that kind of stuff doesn't help, the focus should be in their functionalities and all that could be done to get handy and keep a clearly code should be done, I think we need less C/C++/Obj-C style on swift and I let a question:</div><div><br></div><div>What controlling arrays bounds stands for? being that swift could do this behind the scenes.</div><div><br></div><div><br><br>Em quarta-feira, 13 de abril de 2016, Luis Henrique B. Sousa via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> escreveu:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Another common application would be on pagination systems. For example, this function that I just found randomly:<div><div><div><a href="https://github.com/MrAlek/PagedArray/blob/bf64cbb140cf8bd109483dd749ac40a5f4531dfd/Source/PagedArray.swift#L88" target="_blank">https://github.com/MrAlek/PagedArray/blob/bf64cbb140cf8bd109483dd749ac40a5f4531dfd/Source/PagedArray.swift#L88</a><br></div><div><br></div><div><br></div><div><div><font face="monospace, monospace">public func indexes(pageIndex: Int) -> Range<Index> {</font></div><div><font face="monospace, monospace"> assert(pageIndex >= startPageIndex && pageIndex <= lastPageIndex, "Page index out of bounds")</font></div><div><font face="monospace, monospace"> </font></div><div><font face="monospace, monospace"> let startIndex: Index = (pageIndex-startPageIndex)*pageSize</font></div><div><font face="monospace, monospace"> let endIndex: Index</font></div><div><font face="monospace, monospace"> if pageIndex == lastPageIndex {</font></div><div><font face="monospace, monospace"> endIndex = count</font></div><div><font face="monospace, monospace"> } else {</font></div><div><font face="monospace, monospace"> endIndex = startIndex+pageSize</font></div><div><font face="monospace, monospace"> }</font></div><div><font face="monospace, monospace"> </font></div><div><font face="monospace, monospace"> return (startIndex..<endIndex)</font></div><div><font face="monospace, monospace">}</font></div></div><div><br></div><div><br></div><div>wouldn't be required anymore before accessing the array, having simply something like<br></div><div><br></div><div><span style="font-family:monospace,monospace">> let current = </span><span style="font-family:monospace,monospace">pageIndex * pageSize</span><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">> array[safe: (</font><span style="font-family:monospace,monospace">current</span><font face="monospace, monospace"> - pageSize) ..< (</font><span style="font-family:monospace,monospace">current</span><font face="monospace, monospace"> + pageSize)]</font></div><div><br></div><div>(or <i>truncate</i> according to the user expectation) instead, which in my opinion looks much more elegant and handy.</div><div class="gmail_extra"><div><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><br></div><div><br></div><div>Regards,</div><div><br>- Luis</div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Apr 13, 2016 at 7:37 PM, Vladimir.S via swift-evolution <span dir="ltr"><<a href="javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><br>
On 13.04.2016 19:59, Pyry Jahkola wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>
On 13 Apr 2016, at 17:53, Luis Henrique B. Sousa <<a href="javascript:_e(%7B%7D,'cvml','lshsousa@gmail.com');" target="_blank">lshsousa@gmail.com</a><br></span><span>
<mailto:<a href="javascript:_e(%7B%7D,'cvml','lshsousa@gmail.com');" target="_blank">lshsousa@gmail.com</a>>> wrote:<br>
<br>
(…) I totally agree with @Vladimir that we could have a more clear and<br></span>
/swift-ly/ way to concisely wrap those operations.<span><br>
<br>
The behaviour pointed out by him looks very nice and doable to me.<br>
<br>
a = [1,2,3]<br>
a[-1..<6] - raises runtime error (right behavior by default, doesn't<br>
affect existing code)<br>
a[truncate: -1..<6] - produces [1,2,3] (the very behaviour I proposed<br>
initially)<br>
a[safe: -1..<6] - produces nil (i.e [T]?) (no runtime errors and makes it<br>
easy to handle unexpected results)<br>
</span></blockquote><span>
<br>
I don't feel strongly about this. Yes, if this were shorter to express, it<br></span>
would feel like /nicer/ design. But what Haravikk and Chris L. already said<br>
seems to me as /wiser/ design.<br>
</blockquote>
<br>
<br>
IMO it is not just nicer, it provides you with handy and explicit alternatives.<br>
<br>
In some situations, you are checking bounds and you sure that if you calculated them incorrectly - error will be raised.<br>
But sometimes, you don't need to check exact bounds, probably "take these values, or give me nil of no such".<br>
<br>
I can compare this with Dictionary we have in Swift.<br>
Can you say if it is "wise" to return Optional(T) when we calls dict[somekey] ? Probably it is wise to raise error if there is no such key? (to force us to check the key first).<br>
<br>
The proposed subscript for special situations when you know you need exactly this behavior to make your code clear and readable and you fully controls code&error flow.<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>
<br>
(@Vladimir: Besides, I'm sure `.clamped(to:)` wasn't invented for this<br>
purpose but for doing interval arithmetic on ranges. It just happens to<br>
somewhat work here.)<br>
<br>
– Would this feature really provide a measurable benefit to developers?<br>
– Under which circumstances do you find yourself with a past-the-end upper<br>
bound such as 6 where `a.count == 3`?<br></span>
– …Let alone a /negative/ start index like `-1`?<span><br>
<br>
I find cases like these to be much more common in languages like Python and<br>
Ruby where e.g. `array[-2]` refers to the penultimate element. Swift<br>
doesn't seem to want to go there.<br>
<br>
</span></blockquote>
<br>
Each good feature will provide benefit to developers. For those, who work a lot with arrays/bounds/slices/copies this will provide measurable benefit, IMO.<br>
Can we live without such improvement? Absolutely. Are there more important proposals? Yes. But will this make Swift more elegant, handy, clear? Yes, I believe.<br>
<br>
As for "Under which circumstances.." questions. Well.. something like "get +- 5 elements(at max) with center in some index"<br>
<br>
let a = [1,2,3,4,5,6]<br>
let index = random(0..<a.count)<br>
let result = a[truncate: index-5...index+5]<br>
<br>
or "get 5 elements from index, if no 5 elements from index - return empty array"<br>
<br>
let a = [1,2,3,4,5,6]<br>
let index = random(0..<a.count)<br>
if let result = a[safe: index..<index+5] //[Int]?<br>
{return result}<br>
else<br>
{return []}<br>
<br>
Something like this.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>
For the use cases I can think of, Swift 3—as the proposal currently goes<br></span>
<<a href="https://github.com/apple/swift/blob/swift-3-indexing-model/stdlib/public/core/Collection.swift#L724-L808" rel="noreferrer" target="_blank">https://github.com/apple/swift/blob/swift-3-indexing-model/stdlib/public/core/Collection.swift#L724-L808</a>>—already<span><br>
offers the following suitable methods:<br>
<br>
array[bounds]<br></span>
array.prefix(maxLength)// no precondition<span><br>
array.prefix(upTo: index)<br>
array.prefix(through: index)<br>
array.dropLast(n)// no precondition<br></span>
array.dropFirst(n)// no precondition<span><br>
array.suffix(from: index)<br>
array.suffix(maxLength) // no precondition<br>
<br>
If these feel too clumsy to use, maybe we should focus on making them all<br>
more convenient. Ideally, that suggestion would apply to all `Collection`s.<br>
<br>
— Pyry<br>
<br>
</span></blockquote>
<br>
Yes, some variants can be covered by these methods:<br>
array.prefix(maxLength) -> array[truncate: 0..<maxLength]<br>
array.prefix(upTo) -> array[0..<upTo]<br>
array.prefix(through) -> array[0...through]<br>
<br>
And some has no good alternatives in subscription:<br>
array.suffix(from: index) -> array[truncate: index...Int.max ??<br>
array.suffix(maxLength) -> array[truncate: hm..<br>
<br>
But. As array[bound] returns a copy(slice) of array, it feels natural to have variants of behavior of array[bound], just like you have different variants of prefix() methods.<br>
<br>
So it seems for me like this proposal for subscript variants(safe: & truncate:) is good addition to then proposal you pointed to.<div><div><br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div></div></div></div>
</blockquote></div><br><br>-- <br><div dir="ltr"><div><div dir="ltr"><div>Obrigado.<span></span><span></span></div>Daniel Quirino</div></div></div><br>