-
Notifications
You must be signed in to change notification settings - Fork 16
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
Possibility of implementing this as a facade #5
Comments
Sorry for the delay on this, somehow the notification email got lost in the churn. I'll give it it the requisite thought tonight and let you know, but from what you've said so far it seems utterly reasonable. |
Yeah, I'm on board. Did you want to make the change or shall I? |
it's not high up on my list at the moment but, would be super handy. happy to review a PR if it's useful for you / you get there before i do! |
What is left of this after #13? (It mentioned it was only partial). Or is this intended to stay open until the whole crate is a facade (after rust-lang/rust#104265, provided RFC2832 passes)? |
Great question, I'm at work now, I'll have to rebuild context when I get
home
…On Thu, Dec 15, 2022, 11:38 chrysn ***@***.***> wrote:
What is left of this after #13
<#13>? (It mentioned it was
only partial).
Or is this intended to stay open until the whole crate is a facade (after
rust-lang/rust#104265 <rust-lang/rust#104265>,
provided RFC2832 <rust-lang/rfcs#2832> passes)?
—
Reply to this email directly, view it on GitHub
<#5 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIN7S6GBIRCIN5J4LXOUO3WNNQRNANCNFSM4OYEOS6A>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
hey, would you be interested in feature-gating this to act as a facade so
std
would expose the standard library types andnot(std)
would expose the local crate types? this would make it easier to write libraries that are agnostic over std/no_std, but still work with third party networking components in the std case.this would be useful prior to rust-lang/rfcs#2832 landing and being implemented, and for types not included in this RFC (
SocketAddr
etc.)nominally it would be good to test to ensure each variant provides the same interfaces as part of this (and any variation in interfaces would ideally be resolved, which may be a braking change), but practically introducing the feature-gate without anything else would still help a bunch.
The text was updated successfully, but these errors were encountered: