some editing to better reflect my concern #1
Conversation
| is already legal in Rust today, even though the `F` doesn't need to be a | ||
| `const` function. Since we can't reuse this syntax, do we need a different | ||
| syntax or should the same syntax mean different things for `const` types and | ||
| `const fn` types? | ||
|
|
||
| 2. Opt out bounds might seem unintuitive? |
There was a problem hiding this comment.
I did not edit this part, but given that the exact same thing is called "natural" for dyn Trait, I feel we should adjust one of the two sentences. :)
There was a problem hiding this comment.
It's not my opinion. Iirc I just added it because someone mentioned it.
There was a problem hiding this comment.
So what about removing both this and the "natural", basically avoiding making a judgment?
There was a problem hiding this comment.
I still think it's "natural" or at least consistent to keep dyn some trait specifiers in sync with T: some trait specifiers
There was a problem hiding this comment.
I agree with that. And moreover, I think it is just as natural to keep dyn <specifiers> Trait in sync with <specifiers> fn (both of these are types here, not items/delcarations). Conversely, I think an asymmetry between our two kinds of dynamic dispatch (fn ptrs and dyn Trait) is just as unnatural as an asymmetry between traits dispatching statically or dynamically.
So I am fine with keeping the "natural" here for traits if we also call the same thing "natural" for function pointers.
There was a problem hiding this comment.
extern fn ptrs make no sense -- extern is a property of a function definition, but irrelevant for its type. (We have extern "ABI" fn ptrs, but here extern is just a bad keyword that we use to explicitly specify the ABI. extern "Rust" fn is the exact same thing as fn.)
We don't need dyn unsafe Trait because the Trait declares its methods and whether they are unsafe. That is just like saying that function pointers come with argument and return types which dyn Trait does not -- it is true, and IMO does not change the argument here. It just reflects that dyn Trait is nominal while function pointers are structural.
Imagine a structural version of dyn Trait. It would be dyn trait { fn method1(i32); unsafe fn method2(i64); }. Now a fn ptr is very much the same thing as a dyn trait {...} with a single function. Does this make the symmetry clearer?
There was a problem hiding this comment.
yea, ok, the symmetry in semantics is clear, but I was mainly worried about syntax here 😆
There was a problem hiding this comment.
Ah -- I don't care about syntax, as long as it is consistent. ;) Which is what this is not, hence my comments.
There was a problem hiding this comment.
So what about removing both this and the "natural", basically avoiding making a judgment?
ok let's do that.
There was a problem hiding this comment.
Done. I also reordered the fn ptr and dyn Trait discussion, because as you said dyn Trait is closer to what the RFC discusses otherwise, so this makes for a smoother transition I think.
…olicy Clarify that audits evaluate both moderation policies and their application
There is also https://github.com/rust-lang/const-eval/blob/master/rfcs/const-generic-const-fn-bounds.md but I am not sure if that is still in sync with this branch...