> On May 11, 2017, at 12:56 PM, Ben Cohen via swift-evolution > <[email protected]> wrote: > > >> On May 10, 2017, at 11:13 PM, Brent Royal-Gordon <[email protected] >> <mailto:[email protected]>> wrote: >> >>> On May 10, 2017, at 4:51 PM, Ben Cohen via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> Add a unicodeScalars property to Character, presending a lazy view of the >>> scalars in the character, along similar lines to the one on String. >>> >>> >> >> Might it make sense conform `Character` itself to `Collection`, rather than >> using a view? >> > > Hmm. I don’t think this would be right. The composition of Character is not > fundamental to its very being (unlike String’s composition, where being of > element type Character is an important principle for Swift) – it’s a > lower-level thing that a user can poke at for specific purposes. > > Also, one of the discoveries we’ve made while making String a Collection is > it has some unfortunate effects on code that uses flatMap inapporpriately. > You can use flatMap with a function (Element)->T, and it has the same effect > as map because the function is implicitly converted to (Element)->T? and then > the elements are unwrapped again by the flatMap. But if you were doing this > on String, and then String becomes a Collection, suddenly you get the more > appropriate flatMap that flattens nested collections, and you get a > [Character] back instead of the expected [String]. We’ve been able to put in > compatibility shims to detect this specific case so people can be warned in > Swift 3 compatibility mode, but I fear making Character a collection too may > itself may introduce even more problems, possibly ones we can’t work around > without compiler features. This reason alone might not be enough to rule out > making Character a collection in the future, but it probably rules it out for > Swift 4. >
Also, it’s not clear which unicode scalars should be exposed if Character were a collection. The unicode scalar view inside of Character reflects the scalars that just so happened to comprise the Character in the original String from which it came (*view* being an important word here). If Character were a proper collection, perhaps it makes more sense for it to be a collection of (insert-your-favorite-form) normalized scalars instead. This should be evaluated later, of course. >> Otherwise, I'm in favor. (Though it'd be nice to have *some* way to >> manipulate the `UnicodeScalar`s inside a `Character`, even if >> `RangeReplaceableCollection`'s interface would make preserving its >> invariants too difficult. That could wait, though.) >> >> -- >> Brent Royal-Gordon >> Architechies >> > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
