←back to thread

128 points RGBCube | 1 comments | | HN request time: 0s | source
Show context
jhugo ◴[] No.44498376[source]
> we cannot just require all generic parameters to be Clone, as we cannot assume they are used in such a way that requires them to be cloned.

No, this is backwards. We have to require all generic parameters are Clone, as we cannot assume that any are not used in a way that requires them to be Clone.

> The reason this is the way it is is probably because Rust's type system wasn't powerful enough for this to be implemented back in the pre-1.0 days. Or it was just a simple oversight that got stabilized.

The type system can't know whether you call `T::clone()` in a method somewhere.

replies(4): >>44498401 #>>44498749 #>>44499040 #>>44499325 #
berkes ◴[] No.44498401[source]
> The type system can't know whether you call `T::clone()` in a method somewhere.

Why not?

replies(1): >>44498701 #
jhugo ◴[] No.44498701[source]
Types don't carry behavioral information about what the method does internally. Everything about a method is known from its signature.

The compiler doesn't introspect the code inside the method and add additional hidden information to its signature (and it would be difficult to reason about a compiler that did).

replies(2): >>44498750 #>>44498864 #
delta_p_delta_x ◴[] No.44498750{3}[source]
> Types don't carry behavioral information about what the method does internally.

I was under the impression type inference meant that the implementation of a function directly determines the return type of a function, and therefore its signature and type.

replies(3): >>44498799 #>>44498834 #>>44498836 #
1. jhugo ◴[] No.44498834{4}[source]
While you can sometimes elide the return type (and what you describe only happens in closures — `|| { 0u32 }` is the same as `|| -> u32 { 0u32 }` — methods and free functions must always have an explicitly declared return type), that's not the same thing as being described above.

For the existence of any invocation of `<T as Clone>::clone()` in the method body to be encoded in the method signature, we'd either need some wild new syntax, or the compiler would need to be able to encode hidden information into types beyond what is visible to the programmer, which would make it very hard to reason about its behavior.