[swift-evolution] [Proposal] Higher Kinded Types (Monads, Functors, etc.)

Andrew Bennett cacoyi at gmail.com
Wed Dec 16 08:34:16 CST 2015


Good point Al, I avoided Set for similar reasons. Feel free to substitute
Dictionary for String.CharacterView in my example. Unrelated to this
proposal I would like to see a mapValues method on Dictionary.

The main point though was that you can't unambiguously resolve the return
type. A similar example to yours, is that without higher kind types myMap
on CollectionType could allow this to compile:

let oops: String? = [1,2,3].myMap {"\($0)"}



On Thu, Dec 17, 2015 at 1:13 AM, Al Skipp <al_skipp at fastmail.fm> wrote:

> let myDictionary: [String:Int] = ["test": 1]
> var otherDictionary = myDictionary.myMap { ($0, Float($1)) }
>
> // does not fail:
>
> assert(otherDictionary is [String:Float])
>
>
> The trouble with Dictionary is that peculiar things can happen if we can
> map over keys and return a Dictionary.
>
> let dict = ["a":1, "b":2, "c":3]
> let dict2 = dict.map { ("x", $1 * 2) } // [“x”:6]
>
> We start with a Dictionary with 3 keys and end up with a Dictionary with 1
> key! As the order of the keys is unknown, we have no idea what the value of
> the key will be either, it might be 6, 4 or 2.
>
> Swift currently avoids this bedlam by returning an Array of tuples when
> ‘mapping’ a Dictionary. Strictly speaking this isn’t ‘map’ in the Functor
> sense, but then again Dictionary is a rogue that refuses to obey the
> Functor laws anyway.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151217/43b94b9a/attachment.html>


More information about the swift-evolution mailing list