[swift-evolution] modifying Array<Element> to return Element! when subscripted
Xiaodi Wu
xiaodi.wu at gmail.com
Wed Jun 29 11:03:58 CDT 2016
On Wed, Jun 29, 2016 at 10:06 AM, T.J. Usiyan via swift-evolution <
swift-evolution at swift.org> wrote:
> What about an additional method? No subscripting, just a method that
> throws instead of trapping?
>
What about it? You can add it yourself via extension. What's your case that
it should be in the stdlib?
> On Tue, Jun 28, 2016 at 2:08 PM, Dave Abrahams via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>>
>> on Thu Jun 23 2016, "L. Mihalkovic via swift-evolution" <
>> swift-evolution at swift.org> wrote:
>>
>> >> On Jun 23, 2016, at 6:07 PM, Pranjal Satija via swift-evolution <
>> swift-evolution at swift.org> wrote:
>> >>
>> >> Would modifying array subscripts to return implicitly unwrapped
>> >> optionals be a bad idea? This way, if an array is indexed out of
>> >> bounds,
>> >
>> > Most out of bounds errors originate in bad code. So now instead of
>> > forcing people to rewrite it or at least have more bad code to be more
>> > defensive, this would give an incentive to ignore the original problem
>> > and never learn to code properly.
>>
>> +1; I am opposed to this. If it's not already on the list of
>> commonly-rejected proposals, I'm surprised, as it comes up often.
>>
>> --
>> Dave
>>
>> _______________________________________________
>> 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/20160629/cc949794/attachment.html>
More information about the swift-evolution
mailing list