Thank you, Jens, for your response. I do however disagree with both points you are making. First, you write that sampling collection elements at random is:
> a pretty obscure feature But how can this be? When you teach students how to implement a card playing game in Swift, how do you shuffle the deck? And when you test your code, do you not feed your methods with randomly generated and sampled simulated data, or do so at random intervals? And when you’re simply checking out an idea in the playground, do you not want randomly sampled or reshuffled inputs? Should any of these activities qualify as obscure? As for: > I don’t understand the comparison with capitalizedString; this works after > importing Foundation because... Indeed, nothing after that “because” would help understand what I meant by the comparison. It is the fact of the import that I was trying to highlight. That `Foundation` extends fundamental Standard Library types and protocols (like `String` in this case). The ObjC–Swift bridge is relevant here only in the sense that I would also like sampling methods added to `NSArray`, `NSSet` or `NSDictionary`... At present, when we need a source of random bits on Apple’s platforms, we dip into `Darwin` or `GameplayKit` frameworks. This is fine, and even if it wasn’t, it is unlikely to change (even when new RNG algorithms get introduced). What I would personally like to see, however (and what I was wondering the community feels about), is that one of these frameworks extends Standard Library data types and protocols with this functionality, which most of us gets the taste of right with our first encounters with computer programming and which we continue to rely on throughout our careers. milos > On 10 Apr 2016, at 17:33, Jens Alfke <j...@mooseyard.com> wrote: > > It sounds like you’re suggesting that a “sample” property (that returns a > randomly chosen element) should be added to the standard library? You could > suggest that on the swift-evolution list, though IMHO it seems like a pretty > obscure feature that not many users would need. > > I don’t understand the comparison with capitalizedString; this works after > importing Foundation because of the bridging between String and NSString, > which is an artifact of the Mac/iOS Swift 2.x’s dependency on the Cocoa > frameworks. > > —Jens > >> In the playground: >> >> "works?".capitalizedString // error: value of type 'String' has no >> member 'capitalizedString' >> >> … but: >> >> import Foundation >> “works!”.capitalizedString // “Works!” >> >> Would it not be nice if all the following likewise worked: >> >> import Foundation >> >> (1..<4).sample >> [1,2,3].sample >> "abc".characters.sample >> ["a": 1, "b": 2, "c": 3].sample >> >> Like so many users of Swift, I have extensions >> <http://stackoverflow.com/a/30285125/1409907> of IntegerType, ClosedInterval >> and CollectionType that avail me of the above methods and their family, but >> I’d much rather if such extensions came with Darwin or at least Foundation. >> >> milos
_______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
