Add map(to:) operator

[ra1028]

Refer #597

For example, use as below.

let (signal, observer) = Signal<String, NoError>.pipe()
let triggerSignal = signal.map(to: ())

triggerSignal.observeValues {
    print("trigger `value` events")
}

Discassion

I want to add @autoclosure @escaping, but occur an error(Ambiguous reference to member 'map) on overload map.
So, I propose to name it replace(to:), like below.

public func replace<U>(to value: @autoclosure @escaping () -> U) -> Signal<U, Error> {
    return map { _ in value() }
}

Checklist

• Updated CHANGELOG.md.

[NachoSoto]

Can you add this to SignalProducer too?

[ra1028]

oh, I forgot
will add it.

[NachoSoto]

I think eager evaluation is precisely what we want. If somebody needs lazy evaluation of the value they can make that explicit by using the closure variant.

[mdiep]

I think we should call this map(value:) for consistency. This would match SignalProducer(value:), but it would also match things like skip(value:), filter(value:), which wouldn't make sense with to:. We could also conceivably add mapError(value:), map(error:) and other things.

[NachoSoto]

Can you implement this using lift as well?

[NachoSoto]

Can you implement this using lift?

[ra1028]

done 👍

[NachoSoto]

🎉

[NachoSoto]

@mishagray realized that this produced a regression. I wrote a test case that reproduces it:

let (signal, observer) = Signal<Int, NoError>.pipe()
let mappedSignal = signal.map { $0 as Int? }

// Cannot convert value of type 'Signal<(Int?) -> Int?, NoError>' to specified type 'Signal<Int?, NoError>'
let expectedType: Signal<Int?, NoError> = mappedSignal

I'm sending a PR to fix this.

[mishagray]

This PR breaks some of my existing 'map' code.

        // I have a Signal Producer of UIImage values
	let fetchImage = SignalProducer<UIImage, NoError>(value: UIImage())

        // optionalFetch SHOULD resolve as  SignalProducer<UIImage?, NoError>
	let optionalFetch = fetchImage.map { $0 as UIImage? }

	assert(optionalFetch is SignalProducer<UIImage?, NoError>, "did I get the right type?") 
        // The line above actually gives the compiler warning: "Cast from 'SignalProducer<(UIImage?) -> UIImage?, NoError>' to unrelated type 'SignalProducer<UIImage?, NoError>' always fails"
	assert(!(optionalFetch is SignalProducer<(UIImage?) -> UIImage?, NoError>), "did I get the wrong type?")
       // line above generates compiler warning: "'is' test is always true"

       // Defining the type seems to get the compiler to 'pick' the right version of 'map'.   But this kind of ugly.
	let optionalFetch1: SignalProducer<UIImage?, NoError>  = fetchImage.map { $0 as UIImage? }
	let optionalFetch2: SignalProducer<(UIImage?) -> UIImage?, NoError>  = fetchImage.map { $0 as UIImage? }
       	assert(optionalFetch1 is SignalProducer<UIImage?, NoError>, "did I get the right type?") 
 

[NachoSoto]

I'm proposing renaming this replacingValues(to:) to avoid the bad type inference due to the overload.

[mdiep]

Wat! That does not seem like a valid use of trailing closure syntax. 😕

[NachoSoto]

But Swift doesn't know that :(

[NachoSoto]

Oh wait, I see what you're saying! That seems like a Swift bug then.

[mdiep]

Yes, about to file an issue.

[NachoSoto]

[mdiep]

https://bugs.swift.org/browse/SR-6989

[ra1028]

Oh... 🙇