Comments (9)
To me, at least, those don't seem persuasive enough to dissuade from making dyn
strictly required.
- One can presumably just do
type MyBoxedDynAny<T> = dyn MyBoxedDynAnyTrait<T>;
if you want to expose something as a type instead of a trait. - That use has always felt somewhat like a hack to me, vs a representation like would be done at runtime like
transmute::<{ Neglect { alignment: true, .. } }(...)
or something. Or eventransmute::<{Neglect::Alignment | Neglect::SomethingElse}>(...)
with aconst BitOr
for whatever that type would be. It's certainly a fun hack, while const generics are as limited as they currently are, but I'm still not a fan of it.
from lang-team.
The link to "lang-team design meeting proposal" points to a 404, I assume that is not intended?
from lang-team.
The link in the template is broken. I've changed it to what seems most appropriate.
from lang-team.
@varkor I don't know if this is a good idea or not, but it's worth noting that we could make min_const_generics
(or this specific parsing issue related to it) only available in the new edition, which would avoid the ambiguity in older editions as well. Then, foo + bar
would unambiguously mean dyn foo + bar
in an older edition, and would unambiguously be a const generic operation in the new edition. That would result in better error messages and potentially simplified parsing.
from lang-team.
@joshtriplett: we could, but as the only issue is a diagnostics issue, I think it's still work stabilising on older editions. The usefulness outweighs the occasional diagnostic confusion, I feel.
from lang-team.
Tangentially related, it would be nice to have the option for specific traits and/or specific generic parameters "slots", not to require that dyn
.
The need arises when:
-
implementing custom trait objects with a defined layout, while wanting to be auto-trait generic. The best solution for that right now is to have a phantom generic parameter slot, so as to write stuff such as
MyBoxedDynAny<Send + Sync>
(an example). Currently,deny(bare_trait_objects)
requires a redundantdyn
in that name. -
the second use case is regarding type-level sets, such as the discussed
NeglectStuff
options for the safe-transmute project: withtransmute::<Neglect::Alignment + Neglect::SomethingElse>(...)
from lang-team.
I just ran into another place where it would be helpful for dyn
to be required: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=03e6767e7f9a6ceedf6ac9a213055703
trait Foo : Bar {}
trait Bar {
fn from_integer(x: i32) -> Self;
}
fn make_it<T: Foo>() -> T {
Foo::from_integer(123)
}
It currently gives a book:
error[E0038]: the trait `Foo` cannot be made into an object
--> src/lib.rs:7:5
|
7 | Foo::from_integer(123)
| ^^^^^^^^^^^^^^^^^ `Foo` cannot be made into an object
|
note: for a trait to be "object safe" it needs to allow building a vtable to allow the call to be resolvable dynamically; for more information visit <https://doc.rust-lang.org/reference/items/traits.html#object-safety>
--> src/lib.rs:3:8
|
1 | trait Foo : Bar {}
| --- this trait cannot be made into an object...
2 | trait Bar {
3 | fn from_integer(x: i32) -> Self;
| ^^^^^^^^^^^^ ...because associated function `from_integer` has no `self` parameter
help: consider turning `from_integer` into a method by giving it a `&self` argument
|
3 | fn from_integer(&self, x: i32) -> Self;
| ^^^^^^
help: alternatively, consider constraining `from_integer` so it does not apply to trait objects
|
3 | fn from_integer(x: i32) -> Self where Self: Sized;
| ^^^^^^^^^^^^^^^^^
error[E0308]: mismatched types
--> src/lib.rs:7:5
|
6 | fn make_it<T: Foo>() -> T {
| - - expected `T` because of return type
| |
| this type parameter
7 | Foo::from_integer(123)
| ^^^^^^^^^^^^^^^^^^^^^^ expected type parameter `T`, found trait object `dyn Foo`
|
= note: expected type parameter `T`
found trait object `dyn Foo`
= help: type parameters must be constrained to match other types
= note: for more information, visit https://doc.rust-lang.org/book/ch10-02-traits.html#traits-as-parameters
error[E0038]: the trait `Foo` cannot be made into an object
--> src/lib.rs:7:5
|
7 | Foo::from_integer(123)
| ^^^^^^^^^^^^^^^^^^^^^^ `Foo` cannot be made into an object
|
note: for a trait to be "object safe" it needs to allow building a vtable to allow the call to be resolvable dynamically; for more information visit <https://doc.rust-lang.org/reference/items/traits.html#object-safety>
--> src/lib.rs:3:8
|
1 | trait Foo : Bar {}
| --- this trait cannot be made into an object...
2 | trait Bar {
3 | fn from_integer(x: i32) -> Self;
| ^^^^^^^^^^^^ ...because associated function `from_integer` has no `self` parameter
help: consider turning `from_integer` into a method by giving it a `&self` argument
|
3 | fn from_integer(&self, x: i32) -> Self;
| ^^^^^^
help: alternatively, consider constraining `from_integer` so it does not apply to trait objects
|
3 | fn from_integer(x: i32) -> Self where Self: Sized;
| ^^^^^^^^^^^^^^^^^
error[E0277]: the size for values of type `dyn Foo` cannot be known at compilation time
--> src/lib.rs:7:5
|
7 | Foo::from_integer(123)
| ^^^^^^^^^^^^^^^^^-----
| |
| doesn't have a size known at compile-time
| this returned value is of type `dyn Foo`
|
= help: the trait `Sized` is not implemented for `dyn Foo`
= note: the return type of a function must have a statically known size
error: aborting due to 4 previous errors
It feels rather unlikely that someone wanted the trait type there, and it would be nice for name resolution to be able to find the supertrait function, like it does for methods. (And would fit well with rust-lang/rfcs#2845.)
from lang-team.
This looks similar to rust-lang/rust#65371 which is a hole in the implementation of bare_trait_objects
.
from lang-team.
Closing in favor of rust-lang/rust#83213, as discussed in today's planning meeting. That PR has the outcome of various discussions (and is currently in FCP).
from lang-team.
Related Issues (20)
- Nail down cargo-script syntax proposal HOT 2
- T-types proposal for stabilizing type alias impl Trait (TAIT)
- 2024 Edition Review HOT 1
- Design meeting: resolve ABI issues around target-feature HOT 6
- Website broken HOT 5
- Design meeting: Rust for Linux
- Design meeting: Match ergonomics 2024
- Lang-team RFC guidelines appear to be out of date
- Design meeting: Profiles
- Bounds for RPIT/RPITIT/async fn
- Discuss RFC 2442: Simple postfix macros HOT 3
- Discuss Rust 2024 edition planning: 2024-01-10
- Discuss ideas for GSoC 2024 HOT 2
- Discuss feedback for T-spec sample chapters HOT 1
- Lang discussion: Item-level `const {}` blocks, and `const { assert!(...) }` HOT 1
- Discuss temporary lifetimes 2024 RFC HOT 1
- Discuss arbitrary self types v2 RFC
- Proposal: Remove `i128`/`u128` from the `improper_ctypes` lint HOT 7
- Discuss the never type situation
- Extended triage meeting 2024-03-20 HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from lang-team.