Proposal: Add MapPtr function

[stepan-tikunov]

Proposal: Add MapPtr function

What it does:
Safely transforms a value inside a pointer. If the input pointer is nil, returns nil. Otherwise applies the transform function and returns a pointer to the result.

Code:

func MapPtr[T, R any](x *T, transform func(value T) R) *R {
	if x == nil {
		return nil
	}

	result := transform(*x)

	return &result
}

Example:

// Old way
var userName *string
if user != nil {
    name := strings.ToUpper(user.Name)
    userName = &name
}

// With MapPtr
userName := lo.MapPtr(user, func(u User) string {
    return strings.ToUpper(u.Name)
})

Why we need this:

• Removes error-prone boilerplate nil checks when working with optional values
• Completes the Map family: Map (slice), MapValues (map), MapPtr (pointer)
• Follows lo's philosophy: simple, pure, generic
• Practical for real-world scenarios with optional data

Small addition, big impact on code clarity.

[zaqbez39me]

Hey @stepan-tikunov, jumping in as a fellow contributor. Just wanted to share an honest read on each point.

On removing error-prone boilerplate

The "old way" in your example can already be simplified today with lo.ToPtr:

var userName *string
if user != nil {
    userName = lo.ToPtr(strings.ToUpper(user.Name))
}

So MapPtr on top of what already exists in lo only removes the if block itself, which is pretty standard Go control flow. Calling it "error-prone" is a bit of a stretch, it's a two-liner every Go dev reads instantly.

On completing the Map family
Honestly your strongest argument. The symmetry is real Map for slices, MapValues for maps, MapPtr for pointers as nullable containers. If that's the mental model lo wants to commit to, this fits naturally and I don't think it should be dismissed.

On following lo's philosophy
This one cuts both ways. The function is simple and pure, but that also means any consumer can implement it in five lines with zero edge cases. lo tends to shine on things like GroupBy, Chunk, Intersect where the implementation has real weight. The simpler a function is, the stronger the argument for keeping it in userland rather than adding library surface area.

On practical real-world use
No argument here, optional struct fields are everywhere and the pattern is common enough that this isn't a contrived use case.

---

Overall, this is replaceable today, lo.ToPtr already covers most of the pain and what's left is a plain if block. The Map family consistency argument is the real case for inclusion, but it's more aesthetic than functional. Clean proposal either way, hope this is useful for the discussion!