That's the part that I don't know, would encourage anyone who has a link of that being said (or anyone from the core team) to step in here. Obviously if it's required to have a lazy variant for all collection methods, I'd probably pull back this proposal, as it would automatically be rejected by the core team. (But I hope it's not the case, as that means there's a pretty high barrier of entry for adding more convenience methods to the stdlib).
On Sat, May 21, 2016 at 9:11 PM Dan Appel <[email protected]> wrote: > Correct me if I'm wrong, but isn't part of the goal of lazy collections to > be able to prefix a whole chain of operations with .lazy and have it still > compile (and be more efficient)? If so, then the core team would probably > want both variants in the standard library. > On Sat, May 21, 2016 at 12:16 PM Honza Dvorsky via swift-evolution < > [email protected]> wrote: > >> I see your point, I agree it would definitely be nicer to have both >> variants, but is that a rule that *all* methods on Collection and >> Dictionary etc also have lazy variants? I actually don't know (please tell >> me if you do). >> >> The question here is not really whether to add a lazy variant later (I >> don't think anyone would object to that), but as that would require quite >> substantial refactoring and abstraction change into a Map protocol (which >> will definitely gather a lot of feedback and could drag on for months), I >> don't see why we can't add the regular variant already and benefit from it >> now. Another option is that there won't be demand for the lazy variant, in >> which case it makes even less sense to block the regular variant right now >> (and could even hurt this proposal). >> >> Maybe I'm missing some information about the core team requiring always >> adding both non-lazy and lazy variants, if so, please do tell me so that I >> can re-evaluate my approach. If not, I'd like to keep the thread focused >> strictly on the one method I'm proposing we add, for the benefits and >> examples I provided. >> >> The Dictionary initializers could slightly help things, but it'd require >> nesting if you do more than one level, whereas `mapValues` would allow for >> multiple transformations to be applied in sequence without additional >> nesting (my example from the original pitch would turn into `var >> descriptionTextLengths = Dictionary(Dictionary(repos.mapValues { >> $0["description"].string }).mapValues { $0.characters.count })` which is >> much uglier in my opinion (and kind of breaks the natural left-to-right >> composition). >> >> On Sat, May 21, 2016 at 8:01 PM Haravikk <[email protected]> >> wrote: >> >>> >>> On 21 May 2016, at 15:47, Honza Dvorsky <[email protected]> wrote: >>> >>> While I agree that it'd be nice to add a Map abstraction into which we >>> could move a lot of the Dictionary-ness, my original pitch is *just* about >>> adding the specific implementation of `mapValues` in its regular, non-lazy >>> form. My example was about only keeping a subset of the information in >>> memory in a Dictionary to allow for quick and frequent access (lazy goes >>> against that). I think it'd be better to get that in first, or at least >>> evaluate that separately from a comprehensive refactoring of the >>> Dictionary, which would just accumulate more opinions and slow this >>> specific step down. >>> >>> >>> Sorry, my point was that I think it’s better to wait until we can also >>> do the lazy equivalent and have both done together, otherwise we end up >>> with one map function that can work both lazily and one that never does. >>> Sure that will require a refactoring into a protocol, but it seems to me >>> that it’s better to do that as the first step, then add the feature after >>> that. In the mean time extensions have you well covered for convenience. >>> >>> Another alternative to this feature might be to add a key/value pair >>> constructor to Dictionary (it technically already has one, but it’s >>> variadic only) so you could do something like this: >>> >>> let myTransformedDictionary = Dictionary(myIntegerDictionary.lazy.map { >>> ($0, $1 + 5) }) >>> >>> Since this would be a useful initialiser both now and in future. I >>> dunno, it’s just my opinion, but I find it a bit weird to get half the >>> implementation now, and could lead to misunderstandings with people trying >>> to do myMap.lazy.mapValues (won’t be recognised) and wondering why there >>> isn’t one. >>> >> _______________________________________________ > > >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > -- > Dan Appel >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
