modifying Array<Element> to return Element! when subscripted

Evolution Discussion
1

Would modifying array subscripts to return implicitly unwrapped optionals be a bad idea? This way, if an array is indexed out of bounds, the returned value will be nil, instead of a fatal error. This would allow developers to check for nil before fatal errors are created.

2

If you’re resigned to checking for nil, then why not just check the index to make sure it is in bounds *before* fetching from the array in the first place?

l8r
Sean

···

On Jun 23, 2016, at 11:07 AM, Pranjal Satija via swift-evolution <swift-evolution@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, the returned value will be nil, instead of a fatal error. This would allow developers to check for nil before fatal errors are created.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

3

There is currently an ongoing discussion about this here:

http://article.gmane.org/gmane.comp.lang.swift.evolution/21420

···

On Jun 23, 2016, at 6:07 PM, Pranjal Satija via swift-evolution <swift-evolution@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, the returned value will be nil, instead of a fatal error. This would allow developers to check for nil before fatal errors are created.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

4

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.

···

On Jun 23, 2016, at 6:07 PM, Pranjal Satija via swift-evolution <swift-evolution@swift.org> wrote:

the returned value will be nil, instead of a fatal error. This would allow developers to check for nil before fatal errors are created.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

5

+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.

···

on Thu Jun 23 2016, "L. Mihalkovic via swift-evolution" <swift-evolution@swift.org> wrote:

On Jun 23, 2016, at 6:07 PM, Pranjal Satija via swift-evolution <swift-evolution@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.

--
Dave

6

What about an additional method? No subscripting, just a method that throws
instead of trapping?

···

On Tue, Jun 28, 2016 at 2:08 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote:

on Thu Jun 23 2016, "L. Mihalkovic via swift-evolution" < > swift-evolution@swift.org> wrote:

>> On Jun 23, 2016, at 6:07 PM, Pranjal Satija via swift-evolution < > swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

7

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 Wed, Jun 29, 2016 at 10:06 AM, T.J. Usiyan via swift-evolution < swift-evolution@swift.org> wrote:

On Tue, Jun 28, 2016 at 2:08 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote:

on Thu Jun 23 2016, "L. Mihalkovic via swift-evolution" < >> swift-evolution@swift.org> wrote:

>> On Jun 23, 2016, at 6:07 PM, Pranjal Satija via swift-evolution < >> swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution