[swift-evolution] [Pitch] Add `mapValues` method to Dictionary

[Honza Dvorsky]

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 <dan.appel00 at gmail.com> 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 <
> swift-evolution at swift.org> 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 <swift-evolution at haravikk.me>
>> wrote:
>>
>>>
>>> On 21 May 2016, at 15:47, Honza Dvorsky <jan.dvorsky at me.com> 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
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> --
> Dan Appel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160521/61a76107/attachment.html>