<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Did you consider making the safer, optional overload the "default" and just omit the label?<br><br>Sent from my iPad</div><div><br>On May 6, 2016, at 10:23 AM, Luis Henrique B. Sousa via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div><span style="font-size:12.8px">"bounded" sounds good to me, but I</span> don't know if "optional" is a good choice as it could be highlighted as a reserved keyword:</div><div><br></div><div><div><a href="https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md#detailed-design">https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md#detailed-design</a><br></div></div><div><br></div><div class="gmail_extra"><div class="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">- Luis</div></div></div></div></div></div></div></div></div><div class="gmail_extra"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Fri, Apr 29, 2016 at 5:08 PM, Vladimir.S via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">From my point of view,<br>
truncate -> bounded<br>
lenient -> keep "lenient:" ? "requested:" ? "optional:"?<span class=""><br>
<br>
On 29.04.2016 17:46, Thorsten Seitz wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
Some alternatives to 'safe:'<br>
<br>
existing:<br>
bounded:<br>
valid:<br>
<br>
-Thorsten<br>
<br>
Am 29.04.2016 um 00:20 schrieb Luis Henrique B. Sousa via swift-evolution<br></span>
<<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>>:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
Thanks Vladimir, your considerations and suggestions are totally valid,<br>
I'm going to change the document accordingly.<br>
Also as a non-native English speaker I think that other words could fit<br>
better, such as 'tolerant' or 'permissive' -- but I dunno if they would<br>
look great as a label. We will come up with the right keyword for it.<br>
<br>
In relation to bad code, it could be a valid argument if my initial<br>
proposal was under discussion instead, where the default 'fail fast'<br>
behaviour would be "camouflaged" and bugs would be more difficult to<br>
catch. In this new proposal we have such features explicitly defined,<br>
where the user will be familiar with what it does and what results to<br>
expect for. I don't see a way that it could drive to bad written code.<br>
<br>
- Luis<br>
<br>
On Thu, Apr 28, 2016 at 2:37 PM, Vladimir.S <<a href="mailto:svabox@gmail.com" target="_blank">svabox@gmail.com</a><br></span><div><div class="h5">
<mailto:<a href="mailto:svabox@gmail.com" target="_blank">svabox@gmail.com</a>>> wrote:<br>
<br>
I support this proposal. Probably we all should select the best<br>
labels (truncate/lenient or other). As not native English speaker, I<br>
don't feel like 'lenient' is well-known word or often-used word in<br>
software development. But all this just a details we need to discuss.<br>
<br>
What I think could be improved - is a motivation section. IMO the<br>
main purpose of proposed features is not to "eliminate the need for<br>
validations, reduce the number of fatal errors in runtime" but to<br>
allow us to have more clean code when *such validations just don't<br>
required*, when we just *don't care* about details.<br>
I.e. in situations, when we'll use [max(-1, a.startIndex) ..< min(5,<br>
a.endIndex)] and bounds checking manually to have the same result as<br>
in proposed subscripts.<br>
<br>
I.e. it is just a very handy addition to standard methods for<br>
collections, just like we can get first element by index but we have<br>
handy property '.first' for this purpose. Btw, it does not raise<br>
error, but returns T?. I think you can add notes regarding analogues<br>
with .first / .last properties(and probably with other) in proposal text.<br>
<br>
Someone can argue, that by using these subscripts, coders can write<br>
'bad' code - but I can't accept such an argument - 'bad' coders<br>
already can write 'bad' code with other features of Swift and at the<br>
end they can implement these subscripts in their project and write<br>
'bad' code. Should we stop to introduce handy and explicit feature<br>
for 'good' coders because of this?<br>
<br>
On 28.04.2016 15:11, Luis Henrique B. Sousa via swift-evolution wrote:<br>
<br>
As we have discussed throughout this thread, the initial proposal was<br>
modified to include alternative subscript methods instead of<br>
modifying the<br>
default operator/subscript behaviour.<br>
The first draft is<br>
here:<br>
<a href="https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md" rel="noreferrer" target="_blank">https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md</a><br>
<br>
I've also put this as a gist so that you can leave comments with<br>
respect to<br>
the proposal document itself. Any suggestion or help is very welcome.<br>
<a href="https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8" rel="noreferrer" target="_blank">https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8</a><br>
<br>
Regards,<br>
<br>
- Luis<br>
<br>
On Mon, Apr 11, 2016 at 1:23 PM, Luis Henrique B. Sousa<br>
<<a href="mailto:lshsousa@gmail.com" target="_blank">lshsousa@gmail.com</a> <mailto:<a href="mailto:lshsousa@gmail.com" target="_blank">lshsousa@gmail.com</a>><br></div></div><div><div class="h5">
<mailto:<a href="mailto:lshsousa@gmail.com" target="_blank">lshsousa@gmail.com</a> <mailto:<a href="mailto:lshsousa@gmail.com" target="_blank">lshsousa@gmail.com</a>>>> wrote:<br>
<br>
This proposal seeks to provide a safer ..< (aka half-open range<br>
operator) in order to avoid **Array index out of range**<br>
errors in<br>
execution time.<br>
<br>
Here is my first draft for this proposal:<br>
<br>
<a href="https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/nnnn-safer-half-open-range-operator.md" rel="noreferrer" target="_blank">https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/nnnn-safer-half-open-range-operator.md</a><br>
<br>
In short, doing that in Swift causes a runtime error:<br>
<br>
leta =[1,2,3]<br>
letb =a[0..<5]<br>
print(b)<br>
<br>
> Error running code:<br>
> fatal error: Array index out of range<br>
<br>
The proposed solution is to slice the array returning all<br>
elements that<br>
are below the half-open operator, even though the number of<br>
elements is<br>
lesser than the ending of the half-open operator. So the<br>
example above<br>
would return [1,2,3].<br>
We can see this very behaviour in other languages, such as<br>
Python and<br>
Ruby as shown in the proposal draft.<br>
<br>
This would eliminate the need for verifications on the array size<br>
before slicing it -- and consequently runtime errors in cases<br>
when the<br>
programmer didn't.<br>
<br>
Viewing that it is my very first proposal, any feedback will<br>
be helpful.<br>
<br>
Thanks!<br>
<br>
Luis Henrique Borges<br>
@luishborges<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br></div></div>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>><span class=""><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>
<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
</span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto: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>
</blockquote></blockquote><div class="HOEnZb"><div class="h5">
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto: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></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>