[swift-evolution] [Proposal] More lenient subscript methods over Collections (was: [Proposal] Safer half-open range operator)
Vladimir.S
svabox at gmail.com
Fri Apr 29 11:08:26 CDT 2016
From my point of view,
truncate -> bounded
lenient -> keep "lenient:" ? "requested:" ? "optional:"?
On 29.04.2016 17:46, Thorsten Seitz wrote:
> Some alternatives to 'safe:'
>
> existing:
> bounded:
> valid:
>
> -Thorsten
>
> Am 29.04.2016 um 00:20 schrieb Luis Henrique B. Sousa via swift-evolution
> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>:
>
>> Thanks Vladimir, your considerations and suggestions are totally valid,
>> I'm going to change the document accordingly.
>> Also as a non-native English speaker I think that other words could fit
>> better, such as 'tolerant' or 'permissive' -- but I dunno if they would
>> look great as a label. We will come up with the right keyword for it.
>>
>> In relation to bad code, it could be a valid argument if my initial
>> proposal was under discussion instead, where the default 'fail fast'
>> behaviour would be "camouflaged" and bugs would be more difficult to
>> catch. In this new proposal we have such features explicitly defined,
>> where the user will be familiar with what it does and what results to
>> expect for. I don't see a way that it could drive to bad written code.
>>
>> - Luis
>>
>> On Thu, Apr 28, 2016 at 2:37 PM, Vladimir.S <svabox at gmail.com
>> <mailto:svabox at gmail.com>> wrote:
>>
>> 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>
>> <mailto: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 <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
More information about the swift-evolution
mailing list