[swift-evolution] Eliminate inconsistencies among primary collection types
Nate Cook
natecook at gmail.com
Fri Apr 29 14:49:27 CDT 2016
> On Apr 29, 2016, at 1:57 PM, Wolfgang H. via swift-evolution <swift-evolution at swift.org> wrote:
>
> Inconsistency A. is that “Set” currently is the only collection type conforming to protocol 'Hashable'”. IMHO both “Array” and “Dictionary” should conform to protocol “Hashable”, too.
Set is the only Hashable* collection type because it's the only collection type where all of its values are always Hashable themselves. Array<Element> can be an array of a non-Hashable type; Dictionary<Key: Value> can have a non-Hashable type for Value. If/when Swift gains conditional protocol compliance, arrays and dictionaries of Hashable types could themselves be Hashable, but not until then.
> Inconsistency B. is that “Array<Int>” is typesafe if used as element of an “Array” but is non-typesafe if used as element of “Set” or “Dictionary”. The non-typesafety may result from the mapping of “Array<Int>” to “NSArray“.
Since Array<Element> isn't Hashable, you can't create a Set<Array<Int>>. The type system therefore falls back to using the bridged Objective-C type for Array<Int>, which can provide a hash value based on object identity.
Nate
*For my spell checker's sake, could we rename Hashable to Washable? Thanks
> - - - Wolfgang H.
>
>
>> Am 2016-04-29 17/Fr um 20:18 schrieb Xiaodi Wu - xiaodi.wu at gmail.com:
>>
>> I'm not sure I understand the inconsistency you see. Set and Dictionary require hashable values and keys, respectively. That's just in the nature of what these types are. Do you want Set itself to conform to Hashable?
>>
>> On Fri, Apr 29, 2016 at 12:57 Wolfgang H. via swift-evolution <swift-evolution at swift.org> wrote:
>>
>> A. When trying to declare nested collection types an inconsistency
>> is unveiled:
>>
>>
>> A.1. “Array” as outer type allows for every collection type as inner
>> type (“Int” used as a placeholder for “some other type”):
>>
>> let test_aa: Array<Array<Int>> = []
>> // ok
>>
>> let test_as: Array<Set<Int>> = []
>> // ok
>>
>> let test_ad: Array<Dictionary<Int, Int>> = []
>> // ok
>>
>>
>> A.2. “Set” as outer type allows for “Set” as inner type only:
>>
>> let test_sa: Set<Array<Int>> = []
>> // compile time error “Type 'Array<Int>' does not conform to
>> // protocol 'Hashable'”
>>
>> let test_ss: Set<Set<Int>> = []
>> // ok
>>
>> let test_sd: Set<Dictionary<Int, Int>> = []
>> // compile time error “Type 'Dictionary<Int, Int>' does not
>> // conform to protocol 'Hashable'”
>>
>>
>> A.3. The same is true for “Dictionary” as outer type:
>>
>> let test_da: Dictionary<Array<Int>, Int> = [:]
>> // compile time error “Type 'Array<Int>' does not conform to
>> // protocol 'Hashable'”
>>
>> let test_ds: Dictionary<Set<Int>, Int> = [:]
>> // ok
>>
>> let test_dd: Dictionary<Dictionary<Int, Int>, Int> = [:]
>> // compile time error “Type 'Dictionary<Int, Int>' does not
>> // conform to protocol 'Hashable'”
>>
>>
>> B. When letting Swift infer the type of collections of “Array” from
>> literals another inconsistency comes to light:
>>
>>
>> B.1. “Array” as outer type behaves IMHO perfectly:
>>
>> var testArray = [ [ 1, 2, 4, 8 ], [ 1, 3, 9, 27 ] ]
>> print(testArray.dynamicType)
>> // prints “Array<Array<Int>>”
>> testArray.append( [ 1, "five", 25, 625 ] );
>> // compile time error “Cannot convert value of 'String' to
>> // expected element type 'Int'”; type safe
>>
>>
>> B.2. “Set” as outer type works but there is no type safety:
>>
>> var testSet: Set = [ [ 1, 2, 4, 8 ], [ 1, 3, 9, 27 ] ]
>> print(testSet.dynamicType)
>> // prints “Set<NSArray>”
>> testSet.insert( [ 1, "five", 25, 625 ] )
>> // neither run time nor compile time errors; no type safety
>>
>>
>> B.3. The same goes for “Dictionary” as outer type:
>>
>> var testDictionary = [
>> [ 1, 2, 4, 8 ]: "Powers of Two",
>> [ 1, 3, 9, 27 ]: "Powers of Three",
>> ]
>> print(testDictionary.dynamicType)
>> // prints "Dictionary<NSArray, String>"
>> testDictionary[ [ 1, "five", 25, 625 ] ] = "Powers of Five"
>> // neither run time nor compile time errors; no type safety
>>
>>
>>
>> — — - Wolfgang H.
>>
>>
>> _______________________________________________
>> 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
More information about the swift-evolution
mailing list