# RFC PR: Add \`fmap\` as a \`map\` alternative with a better specification

**URL:** <https://discourse.julialang.org/t/rfc-pr-add-fmap-as-a-map-alternative-with-a-better-specification/138530>\
**Category:** Internals & Design\
**Created:** [July 29, 2026, 6:53pm UTC](https://discourse.julialang.org/t/rfc-pr-add-fmap-as-a-map-alternative-with-a-better-specification/138530 "2026-07-29T18:53:08Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![CameronBieganek](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cameronbieganek/32/6915_2.png) [@CameronBieganek](https://discourse.julialang.org/u/CameronBieganek)\
**Post date:** [July 29, 2026, 6:53pm UTC](https://discourse.julialang.org/t/rfc-pr-add-fmap-as-a-map-alternative-with-a-better-specification/138530/1 "2026-07-29T18:53:08Z")

</div>

I’m looking for feedback on the following RFC PR, which proposes a new `fmap` function with a stricter API than that provided by `map`.

> <https://github.com/JuliaLang/julia/pull/62518>
>
> This is a proposal for a new mapping function called \`fmap\` with a more precise …specification than \`map\`. Of course the \`map\` function is not removed or deprecated by this PR, but future code would be encouraged to use either \`fmap\` or \`Iterators.map\`.
> 
> The \`fmap\` function is inspired by \`fmap\` from Haskell. The output type of \`fmap\` is always "similar" to the input type, where "similar" means the container type is the same but the element type might be different. The \`map\` function does not always follow that rule.
> 
> I would like to develop a consensus on this addition and on the details of the docstring before I move ahead with implementations, so this draft PR currently only includes the docstring for \`fmap\`.

If possible, please add your comments to the PR rather than here on Discourse.