In-place map for MutableCollection

It’s neither here nor there given that we have a consensus that the best name for the proposed function is something that doesn’t have anything to do with map, but I’m genuinely curious about this: you’re saying everything but confirming or denying whether you dislike the form convention in general.

So let me ask you this directly: Are you saying that you like other particular names with form? Or do you dislike them all?


No, I did not ask for “possible” interpretations, I asked whether it was “a realistic point of confusion”; it sounds like you don’t believe that to be the case.

I don't think this is the place for this conversation. Let's keep it focused on the pitch. If either of you is interested in revisiting the form prefix, let's take it to another thread.

In the specific case of defining it as formMap here, I think that it's totally a realistic point of confusion in that it doesn't make a whole lot of sense to me semantically.

3 Likes

No, I’m not at all interested in revisiting the form prefix, but I am very interested in understanding where people are coming from when they approach a design problem such as this.

It’s hard to engage in meaningful conversation when someone deliberately mentions another aim ("+1 to the InPlace suffix…this remains the clearest, best option"/“the entire stdlib sorely needs an audit for consistent availability of mutating and non-mutating counterparts”/“contra extending the confusing, easily misread formFoo convention”) and then refuses to actually confirm that it’s what they’re doing.

So I’m calling it out, and the only place to do that is when and where it happens.

I still think you could solicit this feedback in a new thread or private message. This is different enough from the focus.

1 Like

I’m a big +1 on the concept/functionality.

If we’re going to bike shed on the name, then:

I dislike using the word form as part of the API name, because “form” is just another term for “make”, implying that formMap means I’m creating a map, which is not the case. Ditto formFilter: I’m not making a filter, I’m applying a filter.

I like the “obviousness” of the name mapInPlace although I agree with @Chris_Eidhof that this technically isn’t a map, unless you’re willing to down the road of saying that a (T) → T is a map (which wouldn’t be a hard sell).

I don’t really like mutateInPlace because IMO mutate is an uncommon enough word in English that it can increase the barrier to entry for non-english speakers. However, given that we already use mutate elsewhere in our API, I wouldn’t object strongly to using this term in the name.

TL;DR:

+1 on the functionality
-1 on formMap
+½ on mapInPlace or mutateInPlace

1 Like

If this is the potential confusion to be avoided, then that issue can be easily accommodated with a slight adjustment to formMapped.

1 Like

I like the idea. It seems to promise something along the lines of space efficiency rather than generating a sequence or returning a same-type copy. I’d prefer mutateInPlace or applyInPlace for f(_:T) -> T.

(I considered apply but that might seem to people to be too similar to map and indicate a non-mutating application)

1 Like

The use of mapped in this form would be extremely unconventional. The only usage of mapped in Foundation comes from the NSData methods that deal with mapped memory.

formMapped would get an even stronger -1 from me.

In general, I can agree, but in this particular case I disagree that we’re going too far afield.

Since the focus of this thread is on the most appropriate name for the method, unless it’s already settled that we’re not going to use any name based on “map,” it’ll be important to clarify where people are coming from in terms of mutating vs. nonmutating methods.

If there’s general dissatisfaction with a settled convention, it’s important to (a) air it; and (b) having aired it, deliberately subset that out of this discussion and approach the naming of this particular method based on settled convention.

Here I have to disagree with you as a non-native English speaker. mutate and mutation in general is a core concept of Swift which has to be learned quite early and therfore it would still be a good and acceptable enought prefix from my point of view. However I‘m not saying it‘s the best prefix, for that I have to see a better one first.

4 Likes

That’s fair, and thank you for the perspective. :) Like I mentioned, I’m not firmly opposed to the idea of mutate, so if that’s the naming direction we decide to go, I won’t raise an argument against it.

I suppose I'm confused because you earlier made this assertion:

I'll say again, though, that I'd be happy to move this conversation beyond map completely and focus on non-map naming, since the semantics are different enoudh and both formMap and formMapped don't make sense.

I agree, it’s one of the first words I learned as a programmer (and swift has mutating already). However, to me it doesn’t feel right as part of the name.

We can agree on this :slight_smile:

And by “we,” I mean specifically you and I, and I think @Paul_Cantrell. But, for greater specificity, I don’t mean it as an assertion that all participants of the thread have come to that agreement.

“apply”

C. Keith Ray

Apply is used to mean something rather different in other languages.

Do other languages have a function like the one proposed? And in those languages, what is this function called?

I agree, mutate works as a keyword, but isn’t the best name for a fuction. I also concur that map isn’t the best name here, since the type can’t be changed. Definitely not map if we go with the inout version.

How about:

  • modifyEach / updateEach if we’re going with inout.
  • replaceEach / setEach if we’re not.
3 Likes

“apply”

BTW, “form” is terrible as a verb. I read the verb as meaning “to shape”. I use “create” or “make”. “Form” as a noun makes me expect a screen full of text-entry fields. If “form” is officially part of Swift’s naming patterns, I suggest changing that rule.

C. Keith Ray

https://leanpub.com/wepntk <- buy my book?

http://agilesolutionspace.blogspot.com/

twitter: @ckeithray

http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf

1 Like

Thinking about it further, if we use a verb like mutate/modify/update, then we don’t need “each”—it’s implied. This contrasts with “forEach” where “for” is not a verb—the function argument itself stands in for a verb at the call-site.

So here are some possible spellings:

x.transform{ $0 *= $0 }
x.mutate{ $0 *= $0}
x.modify{ $0 *= $0}
x.update{ $0 *= $0}
x.adjust{ $0 *= $0}
x.toEach{ $0 *= $0}

I kind of like toEach as it contrasts with forEach:

One says “For each element, perform this action”, and the other says “To each element, apply this transformation”.

I like where this is going. Since we have reduce(into:), maybe we could have here intoEach(_:)?