Skip to content

1.x: Feature Request Observable.firstOrDefaultSingle #4277

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
vanniktech opened this issue Aug 3, 2016 · 5 comments
Closed

1.x: Feature Request Observable.firstOrDefaultSingle #4277

vanniktech opened this issue Aug 3, 2016 · 5 comments

Comments

@vanniktech
Copy link
Collaborator

vanniktech commented Aug 3, 2016

How do you guys feel about an overload that is named something along the lines of Observable.firstOrDefaultSingle and basically does the same as Observable.firstOrDefault with the difference of returning a Single<T> instead of Observable<T>?

Edit: Could also maybe be called firstOrDefaultAsSingle

@akarnokd
Copy link
Member

akarnokd commented Aug 3, 2016

What's wrong with firstOrDefault().toSingle() ?

@JakeWharton
Copy link
Contributor

Or switchIfEmpty().toSingle() for async defaults.

@vanniktech
Copy link
Collaborator Author

Nothing is wrong with that, I'm right now using firstOrDefault().toSingle().

@JakeWharton
Copy link
Contributor

I don't like that it conflates two concepts: taking the empty stream and ensuring it's non-empty but also transforming the type from Observable to Single.

@vanniktech
Copy link
Collaborator Author

Closing since if this type of suggestion would be approved (basically transforming Observable in any way into one that only emits one item and then converts itself into Single a lot of other operators would need to get the asSingle matching method e.g. first(), last(), lastOrDefault() for consistency

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants