[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 13:10:50 CDT 2016
Yes @Matthew, I did; my very first draft sought to change the default
subscript method. However, there were some opinions against overriding the
default *fail fast* behaviour as it could result in more bugs and in an
overload to debug. It wasn't set in stone, so I think it's something that
could be discussed if this proposal goes to review.
- Luis
On Fri, May 6, 2016 at 5:22 PM, Matthew Johnson <matthew at anandabits.com>
wrote:
> Did you consider making the safer, optional overload the "default" and
> just omit the label?
>
> Sent from my iPad
>
> On May 6, 2016, at 10:23 AM, Luis Henrique B. Sousa via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> "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
>>
>
> _______________________________________________
> 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/2f7245fa/attachment.html>
More information about the swift-evolution
mailing list