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

Luis Henrique B. Sousa lshsousa at gmail.com
Fri May 6 10:23:28 CDT 2016


"bounded" sounds good to me, but I don't know if "optional" is a good
choice as it could be highlighted as a reserved keyword:

https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md#detailed-design

- Luis

On Fri, Apr 29, 2016 at 5:08 PM, Vladimir.S via swift-evolution <
swift-evolution at swift.org> wrote:

> 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
>>>
>> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160506/f9daab01/attachment.html>


More information about the swift-evolution mailing list