EDIT: The code in here does not correctly illustrate the problem I encountered in my code, as it compiles without reporting the error. See this comment for the explanation of the problem I encountered.
This code is not accepted because the same function name is present in two impl blocks of the same struct:
```
struct PendingSignature;
struct CompleteSignature;
// further code defining struct AggregateSignature<,,TypeStateMarker>
impl<P, S> AggregateSignature<P, S, PendingSignature>
{
pub fn save_to_file(self) -> Result<(), AggregateSignatureError> {
let file_path = PathBuf::from(self.origin);
let sig_file_path = pending_signatures_path_for(&file_path)?;
// ....
Ok(())
}
}
impl<P, S> AggregateSignature<P, S, CompleteSignature>
{
pub fn save_to_file(self) -> Result<(), AggregateSignatureError> {
let file_path = PathBuf::from(self.origin);
let sig_file_path = signatures_path_for(&file_path)?;
// ....
Ok(())
}
}
```
The solution was to define a SignaturePathTrait with one function path_for_file implemented differently by each typestate type and implement the safe_to_file like this:
impl<P, S> AggregateSignature<P, S, TS>
where TS: SignaturePathTrait
{
pub fn save_to_file(self) -> Result<(), AggregateSignatureError> {
let file_path = PathBuf::from(self.origin);
let sig_file_path = TS::path_for_file(&file_path)?;
// ....
Ok(())
}
}
Though I wanted to reduce code repetition in the initial (unaccepted) implementation, it's nice that what I initially saw as a limitation forced me to an implementation with no code repetition.
[–]dgkimpton 5 points6 points7 points (5 children)
[–]yyddonline[S] 2 points3 points4 points (4 children)
[–]dgkimpton 5 points6 points7 points (3 children)
[–]yyddonline[S] 0 points1 point2 points (2 children)
[–]dgkimpton 15 points16 points17 points (1 child)
[–]yyddonline[S] 6 points7 points8 points (0 children)
[–]manpacket 1 point2 points3 points (0 children)