Apologies, please remove the line "Right now myArray[100] = nil gives you EXC_BAD_INSTRUCTION." from my previous email so it makes more sense to read.
On Mon, Jun 6, 2016 at 12:02 PM Rob Norback <rnorb...@gmail.com> wrote: > First of all, thank you all for bringing me up to date so quickly. I > looked over the proposal and it looks awesome. > > But as Chris mentioned, this doesn't solve the expected behavior and > ambiguity of ```Array<Int?>``` > > In this case I would expect the default behavior (myArray[4]) without > using myArray[checking: 4] should return a nil in this case. > > And Chris, I think it would make the most sense to have myArray[0] = nil > to be stored if the index is in Range, and for myArray[100] = nil to give a > warning of no assignment being made because index is out of range, kind of > like an unused variable. Right now myArray[100] = nil gives you > EXC_BAD_INSTRUCTION. Then if you assigned myArray[100] = 200, that would > have to simply change the Range. > > Chris, I honestly have to think more about that ambiguity with > dictionaries. > > I can see that this would definitely need some further fleshing out, but > it seems to be sufficiently different from Luis' proposal to perhaps merit > it's own proposal. > > It's up to you Luis, but I think this might be a bit more controversial > then the changes you've proposed, making it possible for your proposal > getting rejected. (I want your proposal accepted, since I would use those > features today). Partial acceptance of a proposal doesn't seem to be a > thing. (Once again please correct me if I'm wrong). > > On Mon, Jun 6, 2016 at 11:46 AM Luis Henrique B. Sousa <lshso...@gmail.com> > wrote: > >> Thanks Vladimir, >> >> The correct link is this one (with the additional min/max operations in >> the implementation): >> >> https://github.com/luish/swift-evolution/blob/proposal-lenient-collection-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md >> >> Here is the pull request on the swift-evolution repo: >> https://github.com/apple/swift-evolution/pull/328 >> >> Any help or suggestion to improve the proposal is welcome. :-) >> >> - Luis >> >> On Mon, Jun 6, 2016 at 6:10 PM, Vladimir.S via swift-evolution < >> swift-evolution@swift.org> wrote: >> >>> Please find this draft of proposal(hope this is correct link for latest >>> version): >>> >>> https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md >>> >>> The main idea is to introduce 2 new subscript methods: [clamping:] and >>> [checking:] >>> >>> There was discussion in "[Proposal] More lenient subscript methods over >>> Collections" and (older) "[Proposal] Safer half-open range operator" >>> >>> >>> On 06.06.2016 19:50, Rob Norback via swift-evolution wrote: >>> >>>> Hi Everyone! >>>> >>>> This is my first time emailing the swift evolution list, so if this >>>> topic >>>> has already been discussed please let me know. I looked through all the >>>> accepted and rejected proposals and it doesn't seem to be on there. >>>> >>>> The main thought is that dictionaries return optionals, so why not >>>> arrays? >>>> Or other CollectionTypes for that matter. I would think this would be >>>> the >>>> expected behavior in this situation: >>>> >>>> var myArray:[String?] = [] >>>> print(myArray[4]) >>>> // EXC_BAD_INSTRUCTION, but could just be Optional(nil) >>>> >>>> Then you could do things like >>>> >>>> if let arrayValue = myArray[4] { >>>> // do something >>>> } >>>> >>>> Of course you could simply check with with the count, but considering >>>> Swift's use of optionals to represent empty variables rather than >>>> erroring >>>> out or returning an empty String, I think this functionality would be >>>> appropriate to include in the Swift standard library. >>>> >>>> And there's about 15,000 people who've looked for this functionality in >>>> the >>>> last year: >>>> >>>> http://stackoverflow.com/questions/25329186/safe-bounds-checked-array-lookup-in-swift-through-optional-bindings >>>> . >>>> >>>> Please let me know what you think. >>>> >>>> Best, >>>> Rob Norback >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> >>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution