I think you're right Vladimir. After having this discussion I've changed my opinion on normal arrays returning optionals. I don't think that's a good idea as its not explicit and is unexpected behavior.
I'd simply like to draft a proposal that has arrays of optionals returning optionals for all indicies with no 'Index out of bounds errors' as I think it's explicit [Int?] and closer to expected behavior. I'd need to flesh out how assignment would behave differently for an array of optionals since assigning a value out of bounds would likely have a different expected effect as well. > On Jun 7, 2016, at 8:33 AM, Vladimir.S <[email protected]> wrote: > > It seems like you are mixing two proposals: optional result of non-optional > array and return value of optional array. > > I'm commenting the first - as it was already discussed earlier and based on > community reaction on it - I believe it will not be supported again. Array is > expected to fail fast when we access with wrong index. > But let's hear other opinions, may be I'm wrong. > > As for second proposal/problem with [Int?] - I don't remember such > discussion, so probably you should create a separate thread for it. It seems > like I don't understand the problem with [Int?] in details, so have no > opinion right now. IMO dictionary [Type1:Type2?] is a special case where you > need to use myDict.keys.contains(keyValue) first to determinate if you have a > value for key and after this you can get the value itself(which is Optional). > >> On 07.06.2016 16:42, Rob Norback wrote: >> Vladimir, thank you for pointing me to the discussion again. I read through >> the entire thing. And I didn't see a consensus around [Int?]. >> >> The main argument against was that it would allow the developer to be clumsy >> and remain unaware of a problem in the code because the choice is not >> explicit enough. >> >> The main argument for is that dictionaries already do this, so why don't we >> have to explicitly check if a dictionary key is within bounds? >> >> IMO casting an array to [Int?] is an explicit choice. One I would expect to >> always return an optional from a subscript. A [Int] array should still fail >> fast. >> >> I'd like to clearly understand the downside of swift behaving this way, and >> why a proposal like this would not be supported. Not to be confrontational, >> but simply to expand my own perspective. Perhaps some more explicit >> examples of developer laziness that could cause major problems. I find I >> always have to be much more careful when coding with optionals. >> >>>> On Jun 7, 2016, at 5:48 AM, Vladimir.S <[email protected]> wrote: >>>> >>>> On 06.06.2016 21:02, Rob Norback 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. >>> >>> As Luis already noted, there was a discussion started with exactly the same >>> suggestion : return optional for wrong index/range. During the discussion >>> consensus was(I believe so) found that such proposal could not be >>> supported. But, as an alternative, special explicit syntax for >>> optional/checking results for index/range parameter was suggested. I'd >>> recommend to read messages of these discussions. >>> >>> As for [Int?], I believe we need no any additional solution for this >>> special case: you have to check if index is in array's bounds and if it is, >>> get value using standard subscript method. >>> >>>> >>>> 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 <[email protected] >>>> <mailto:[email protected]>> 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 >>>> <[email protected] <mailto:[email protected]>> 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 >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >> _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
