녹 기능에서 유형에 주석을 추가 할 때 "예상 유형 인수"오류가 발생하는 이유는 무엇입니까?

Question

나는 Rust의 capnproto library으로 놀고있다. 녹 어떤 상황에서 유형을 추론 할 수 있기 때문에,이 같은 일을 수행 할 수 있습니다

let mut message = ::capnp::message::Builder::new_default(); 

메시지의 종류를 알 필요없이. message에 대한 참조를 함수에 전달하려면 함수에 예상 할 수있는 내용을 알려주는 메시지가 무엇인지 알아야합니다.

일반적으로이 작업을 수행하는 편리한 방법이 있습니까?

지금까지 나는 다음과 같은 짓을 : 컴파일러 오류와 함께 실패

let testing:() = message; 

:

error[E0308]: mismatched types 
    --> src/main.rs:197:18 
    | 
197 |     let temp:() = message; 
    |       ^^^^^^^ expected(), found struct `capnp::message::Builder` 

그러나 나는 다음과 같이 내 기능에 주석을 입력 할 때 :

fn example_fn(message: capnp::message::Builder) {...} 

다음과 같은 오류 메시지가 표시됩니다.

,210

error[E0243]: wrong number of type arguments: expected 1, found 0 
    --> src/main.rs:72:32 
    | 
72 | fn dump_capnp_to_file(message: capnp::message::Builder, filename: &str) { 
    |        ^^^^^^^^^^^^^^^^^^^^^^^ expected 1 type argument 

오류 : 나는 C++ 배경에서 오는 녹 매우 새로 온 이전 오류

로 인해 중단; 이 신참 질문이라면 미안 해요!

Answer 1

녹슬림 은 기능 매개 변수 위치에서 유추 유형이 아닙니다. Rust language FAQ이 상태로이, 디자인입니다 : 다른

fn dump_capnp_to_file(message: capnp::message::Builder<SomeType>, filename: String) { 
//             ^^^^^^^^^^ 

또는합니다 capnp::message::Builder<A> 이후

Why aren't function signatures inferred?

In Rust, declarations tend to come with explicit types, while actual code has its types inferred. There are several reasons for this design:

• Mandatory declaration signatures help enforce interface stability at both the module and crate level.

• Signatures improve code comprehension for the programmer, eliminating the need for an IDE running an inference algorithm across an entire crate to be able to guess at a function’s argument types; it’s always explicit and nearby.

• Mechanically, it simplifies the inference algorithm, as inference only requires looking at one function at a time.

는 형식 매개 변수 A 소요, 당신은 값을 A 제공하여 매개 변수의 형태를 한정 할 필요가

fn dump_capnp_to_file<A>(message: capnp::message::Builder<A>, filename: String) { 
//     ^^^         ^^^ 

가에 경계를 퍼팅 : 함수는 또한 어떤 종류 A를 일반적인 받아 들일 수 있도록

마지막 옵션을 사용하면 기능 내에 message으로 다른 작업을 수행 할 수 있도록 추가 trait bounds이 필요할 수 있습니다. 예를 들어 message을 다른 스레드로 보내려면 Builder<A>이 Send을 구현해야합니다.

impl <A> Send for Builder<A> where A: Send + Allocator 

A가 Send 및 Allocator 구현에만 Builder<A>가 Send을 구현할 수 있지만 것을 의미 Builder는 다음 IMPL (reference)을 갖는다.또한

fn dump_capnp_to_file<A>(message: capnp::message::Builder<A>, filename: String) 
    where A: Send + Allocator 
{ 
    // multi-threaded code... 
} 

(아마 약간 더 나은), 직접 Send와 Builder<A>을 결합 : 당신은 당신의 자신의 바운드 (요구 사항) 것을 A에 할 수

fn dump_capnp_to_file<A>(message: capnp::message::Builder<A>, filename: String) 
    where capnp::message::Builder<A>: Send 

그런 다음 당신은 단지 dump_capnp_to_file를 호출 할 수 있습니다 Send을 구현하는 Builder에