fix: tap and andThen fallthrough function

[patroza]

fixes for example:

declare const foo: (x: number) => Effect.Effect<void>;
Effect.succeed(true).pipe(Effect.tap(foo)); // no error
Effect.succeed(true).pipe(Effect.tap(x => foo(x))); // error

[changeset-bot]

🦋 Changeset detected

Latest commit: 7789d37

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 15 packages

Name	Type
effect	Patch
@effect/cli	Patch
@effect/experimental	Patch
@effect/opentelemetry	Patch
@effect/platform-browser	Patch
@effect/platform-bun	Patch
@effect/platform-node-shared	Patch
@effect/platform-node	Patch
@effect/platform	Patch
@effect/printer-ansi	Patch
@effect/printer	Patch
@effect/rpc-http	Patch
@effect/rpc	Patch
@effect/schema	Patch
@effect/typeclass	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[mikearnaldi]

Mmm what about Effects that are functions? Like the proxy ones from the new tag

[patroza]

Mmm what about Effects that are functions? Like the proxy ones from the new tag

What about them? It they match the supported function signature for andThen/tap, then they’re golden. Otherwise they are (I believe) rightfully rejected.

[mikearnaldi]

I think if an arg is both a function and an effect we have to force () => because the impl will take a choice, either there is an isFunction or isEffect. Quite a conondrum...

[patroza]

I think if an arg is both a function and an effect we have to force () => because the impl will take a choice, either there is an isFunction or isEffect. Quite a conondrum...

I see, seems like a related topic, how is it affected by this change?

[mikearnaldi]

It's not affected but related, with the intro of effect.tag we can't basically distinguish functions from effects, it is an issue for tacit usage

…

On Fri, 8 Mar 2024, 18:25 Patrick Roza, ***@***.***> wrote: I think if an arg is both a function and an effect we have to force () => because the impl will take a choice, either there is an isFunction or isEffect. Quite a conondrum... I see, seems like a related topic, how is it affected by this change? — Reply to this email directly, view it on GitHub <#2264 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFZAKCVBJRRXCBXUDLQTOKLYXHYADAVCNFSM6AAAAABEM66QGKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBWGEYDOOJZGA> . You are receiving this because your review was requested.Message ID: ***@***.***>

[patroza]

It's not affected but related, with the intro of effect.tag we can't basically distinguish functions from effects, it is an issue for tacit usage

alright, would at least like to get the bug fix merged so that users stop getting bit by it.
In the meantime we can look into it. (Though I guess to distribute it we would need to revert Effect.tag then)
From my gut feeling though; isn’t the proxy hiding the internals on access? On phone. Would need some test cases I guess

[tim-smart]

I think there are a few other places where we assume an Effect isn't a function, will need to hunt them down.

[patroza]

It's not affected but related, with the intro of effect.tag we can't basically distinguish functions from effects, it is an issue for tacit usage

I see now yes, that's certainly 'fun' :D

[patroza]

It's not affected but related, with the intro of effect.tag we can't basically distinguish functions from effects, it is an issue for tacit usage

How about https://github.com/Effect-TS/effect/pull/2266/files#diff-1eaca66f74be66210f25595750619630e4d14443b5ddaa1f2f8a265256432778R5292