Select trait exposes private types #8422
Comments
|
I both agree and disagree. On the one hand, I'm not particularly proud of it; it was just the only way I could think of to hide the internal types in On the other hand, I see it less as "select uses a type that doesn't exist", and more as "Select is an opaque trait, that is somehow/magically implemented by X, Y, and Z types of ports, which are the only things select() can be used on." |
|
FWIW Haskell does this a lot so you're in good company. I agree it's not super nice. I don't know what a cleaner way could be. (Exposing the trait and hiding the methods maybe, but that didn't generate too much enthusiasm last time I mentioned it.) |
|
No longer a problem after #10830 |
Dylan-DPC-zz
pushed a commit
to Dylan-DPC-zz/rust
that referenced
this issue
Jul 11, 2021
…n514 Rustdoc: Change all 'optflag' arguments to 'optflagmulti' Because specifying these flags multiple times will never be discernibly different in functionality from specifying them a single time, there is no reason to fail and report an error to the user. This might be a slightly controversial change. it's tough to say, but it's hard to imagine a case where somebody was depending on this behavior, and doing this seem actively better for the user. This originally came up in discussion of a fix for [Cargo rust-lang#8373](rust-lang/cargo#8373), in [Cargo PR rust-lang#8422](rust-lang/cargo#8422). The issue is that Cargo will automatically add things like `--document-private-items` to binaries, because it's the only thing that makes sense there. Then some poor user comes along and adds `--document-private-items` to their `rustdoc` flags for the project and suddenly they're getting errors for specifying a flag twice and need to track down which targets to actually add it to without getting duplicates for reasons they won't understand without deep understanding of Cargo behavior. We're apparently hesitant to inspect `rustdoc` flags provided by the user directly in Cargo, because they're supposed to be opaque, so looking to see if it's already provided before adding it is evidently a non-starter. In trying to resolve that, one suggestion I came up with was to just change `rustdoc` to support passing the flag multiple times, because the user's intent should be clear and it's not *really* an error, so maybe this is a case of 'be permissive in what you accept'. This PR is an attempt to do that in a straightforward manner for purposes of discussion.
JohnTitor
added a commit
to JohnTitor/rust
that referenced
this issue
Jul 11, 2021
…n514 Rustdoc: Change all 'optflag' arguments to 'optflagmulti' Because specifying these flags multiple times will never be discernibly different in functionality from specifying them a single time, there is no reason to fail and report an error to the user. This might be a slightly controversial change. it's tough to say, but it's hard to imagine a case where somebody was depending on this behavior, and doing this seem actively better for the user. This originally came up in discussion of a fix for [Cargo rust-lang#8373](rust-lang/cargo#8373), in [Cargo PR rust-lang#8422](rust-lang/cargo#8422). The issue is that Cargo will automatically add things like `--document-private-items` to binaries, because it's the only thing that makes sense there. Then some poor user comes along and adds `--document-private-items` to their `rustdoc` flags for the project and suddenly they're getting errors for specifying a flag twice and need to track down which targets to actually add it to without getting duplicates for reasons they won't understand without deep understanding of Cargo behavior. We're apparently hesitant to inspect `rustdoc` flags provided by the user directly in Cargo, because they're supposed to be opaque, so looking to see if it's already provided before adding it is evidently a non-starter. In trying to resolve that, one suggestion I came up with was to just change `rustdoc` to support passing the flag multiple times, because the user's intent should be clear and it's not *really* an error, so maybe this is a case of 'be permissive in what you accept'. This PR is an attempt to do that in a straightforward manner for purposes of discussion.
flip1995
pushed a commit
to flip1995/rust
that referenced
this issue
Mar 14, 2022
…logiq new lint: `only_used_in_recursion` changed: - added `only_used_in_recursion`. - fixed code that variables are only used in recursion. - this would not lint when `unused_variable` This fixes: rust-lang#8390 ----- changelog: add lint [`only_used_in_recursion`]
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The
Selecttrait - a public interface - uses the following pattern to hide private implementation details:This is the only place where we use this pattern and I think it's kind of dubious -
Select's signature refers to a type that, from the user's perspective, doesn't exist. It's a leaky abstraction.There may be similar patterns that are more palatable but uses a private enum variant - the enum type is public but opaque.
The text was updated successfully, but these errors were encountered: