Thanks a lot ! Looks great ✨

In my environment, "on()" and "on(&canceller)" are displayed in code completion.
I'm afraid it might be confusing a little bit. Do you have any ideas to suppress them?
I think we can use optional for args but I'm not sure.

@tamamachi
Yes, I understand your saying.
Normally, we don't usually see this mysterious &canceller inout parameter in any other Promises libraries, but it is actually a recommended implementation in order to precisely control lifetime of registered closures (although many users might think this signature awkward...)

Since I have already implemented this &canceller feature in other methods e.g. then(&canceller), I think it is reasonable to continue adding for on() as well for now. Then, next major version bump will be the time to rethink of these implementations again.

Oh, I meant following 4 candidates were shown and first 2 ones were thought to be unnecessary:

• on() - unnecessary
• on(&canceller) - unnecessary
• on(success, failure) - good
• on(&canceller, success, failure) - good

I think this is because default values are specified for args, so maybe we can change the signature
from like
on(success success: Value -> Void = { _ in }, failure: ErrorInfo -> Void = { _ in }) -> Self
to, sort of,
on(success success: (Value -> Void)?, failure:(ErrorInfo -> Void)?) -> Self

How do you think?

Yes, having &canceller parameter is always a downside, but AFAIK, it's not possible remove due to Swift's inout behavior which can't use default parameter.

Your suggestion on changing arguments to Optional is better, so I fixed it in 3ae32c6. But still, I kept using default parameters for success and failure because there will be needs to omit one of those argument, i.e. calling on(success:) and on(failure:).

I think it's important to support simple & consistent API (method signature) more than code completion. (In general, using default parameters easily get worse code completion...)

BTW, even though things may get better, I'm not having plan to rename on(success:) & on(failure:) to separate names e.g. onSuccess() and onFailure() just because it will make confusion with current success() & failure().

Now it looks all goid for me! 💯
I agree with you about not separating .on method.
I don't mind anything about cancellers 😉

Thanks for check!
I'll bump new version for this tonight ;)

Bumped ver 4.1.0. @tamamachi Thanks again!

Thanks! 🍻