[swift-evolution] [Proposal] More lenient subscript methods over Collections (was: [Proposal] Safer half-open range operator)

[Vladimir.S]

I support this proposal. Probably we all should select the best labels 
(truncate/lenient or other). As not native English speaker, I don't feel 
like 'lenient' is well-known word or often-used word in software 
development. But all this just a details we need to discuss.

What I think could be improved - is a motivation section. IMO the main 
purpose of proposed features is not to "eliminate the need for validations, 
reduce the number of fatal errors in runtime" but to allow us to have more 
clean code when *such validations just don't required*, when we just *don't 
care* about details.
I.e. in situations, when we'll use [max(-1, a.startIndex) ..< min(5, 
a.endIndex)] and bounds checking manually to have the same result as in 
proposed subscripts.

I.e. it is just a very handy addition to standard methods for collections, 
just like we can get first element by index but we have handy property 
'.first' for this purpose. Btw, it does not raise error, but returns T?. I 
think you can add notes regarding analogues with .first / .last 
properties(and probably with other) in proposal text.

Someone can argue, that by using these subscripts, coders can write 'bad' 
code - but I can't accept such an argument - 'bad' coders already can write 
'bad' code with other features of Swift and at the end they can implement 
these subscripts in their project and write 'bad' code. Should we stop to 
introduce handy and explicit feature for 'good' coders because of this?

On 28.04.2016 15:11, Luis Henrique B. Sousa via swift-evolution wrote:
> As we have discussed throughout this thread, the initial proposal was
> modified to include alternative subscript methods instead of modifying the
> default operator/subscript behaviour.
> The first draft is
> here: https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md
>
> I've also put this as a gist so that you can leave comments with respect to
> the proposal document itself. Any suggestion or help is very welcome.
> https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8
>
> Regards,
>
> - Luis
>
> On Mon, Apr 11, 2016 at 1:23 PM, Luis Henrique B. Sousa <lshsousa at gmail.com
> <mailto:lshsousa at gmail.com>> wrote:
>
>     This proposal seeks to provide a safer ..< (aka half-open range
>     operator) in order to avoid **Array index out of range** errors in
>     execution time.
>
>     Here is my first draft for this proposal:
>     https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/nnnn-safer-half-open-range-operator.md
>
>     In short, doing that in Swift causes a runtime error:
>
>     leta =[1,2,3]
>     letb =a[0..<5]
>     print(b)
>
>     > Error running code:
>     > fatal error: Array index out of range
>
>     The proposed solution is to slice the array returning all elements that
>     are below the half-open operator, even though the number of elements is
>     lesser than the ending of the half-open operator. So the example above
>     would return [1,2,3].
>     We can see this very behaviour in other languages, such as Python and
>     Ruby as shown in the proposal draft.
>
>     This would eliminate the need for verifications on the array size
>     before slicing it -- and consequently runtime errors in cases when the
>     programmer didn't.
>
>     Viewing that it is my very first proposal, any feedback will be helpful.
>
>     Thanks!
>
>     Luis Henrique Borges
>     @luishborges
>
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>