So, this is basically just TryInto<DerivationPath, Error=Error>? Wish we could just use it directly (1.34.0), but if we can't maybe it would be better to just name it TryIntoDerivationPath to make the future transition easier? There might be some little kinks wrt such a transition, but since rust-bitcoin can still do breaking changes on ongoing basis, there's no point in worrying too much about it.

Yes, if we were >=1.34, it would be TryInto. Regarding current naming, many Rust Into/FromSomething have the name without Try even if they fail (FromStr for instance) and I do not know any counter-examples of traits named with Try... other than TryInto/From themselves. Also this will change method naming, which will hardly derive from the naming used across this crate (where from_... usually failiable)

Isn't this one of those constructions where whenever you implement IntoDerivationPath for a type, cargo will complain "can't allow this impl because rust-bitcoin can implement From<T> for DerivationPath and then this implementation is conflicting"? I bumped into that before.

@dr-orlovsky did you try this?

There is a good solution for that which I use widely: trait implementation strategies and holder. Proposed by @Kixunil.

A sample can be found here:
https://github.com/LNP-BP/rust-lnpbp/blob/master/src/paradigms/strict_encoding.rs#L298-L445

And, actually, with this downstreams would not need to impl IntoDerivationPath at all, just do a Into<DerivationPath> impl and everything else will work. This is another reason of having this as a trait

do you have a link to this trait thing?

But did you try to implement IntoDerivationPath on a foreign type already?

do you have a link to this trait thing?

Sorry, which one? Strategy? I gave it above

I don't understand how the linked code addresses Steven's concern about Rust's coherence rules

There are three problems we are mixing here.

1. Implementing foreign traits for foreign types. There is nothing specific for this problem with this PR, it's a common rust issue and the only way of addressing it is to do either wrapped data type or do a new marker trait with generic dependency on the foreign one (like pub trait NewOne where Self: ForeignOne { /* repeat all methods from ForeignOne */ }) and implement it on foreign data types. I do not know why and how we started discussion this problem, b/c again there is nothing in this commit which makes this problem anyhow harder to solve.

2. Implementing trait for a generic type ("blanket implementation") more than once (applies both for local and foreign traits) - or implement foreign trait for a concrete type where there is some blanket implementation in the upstream. The solution is to use special pattern by @Kixunil. I use it widely and have a special helper type here: https://github.com/LNP-BP/rust-amplify/blob/master/src/strategy.rs#L26-L45

   With that helper type you can write the following code, which will provide you with efficiently multiple blanket implementations of some trait SampleTrait:

   // Define strategies, one per specific implementation that you need, 
   // either blanket or concrete
   pub struct StrategyA;
   pub struct StrategyB;
   pub struct StrategyC;
   
   // Define a single marker type
   pub trait Strategy {
       type Strategy;
   }
   
   // Do a single blanket implementation using Holder and Strategy marker trait
   impl<T> SampleTrait for T
   where
       T: Strategy + Clone,
       amplify::Holder<T, <T as Strategy>::Strategy>: SampleTrait,
   {
        // Do this for each of sample trait methods:
        fn sample_trait_method(&self) {
            amplify::Holder::new(self.clone()).sample_trait_method()
        }
   }
   
   // Do this type of implementation for each of the strategies
   impl<T> SampleTrait for amplify::Holder<T, StrategyA>
   where
       T: Strategy
   {
       fn sample_trait_method(&self) {
           /* ... write your implementation-specific code here */
       }
   }
   
   // Finally, apply specific implementation strategy to a concrete type
   // (or do it in a blanket generic way) as a marker:
   impl Strategy for ConcreteTypeA {
       tyoe Strategy = StrategyA;
   }

3. Implementing type IntoDerivationPath from this PR on some concrete type in downstream dependency. This should not be done, instead one should implement Into<DerivationPath> and will get into_derivation_path() method for free, thanks to a blanket implementation from this PR, and, if for any wired (and unrecommended) reason he'd like to do a direct implementation of IntoDerivationPath for some concrete type or another blanket, he should use solution from pt.2.

Heh, sounds like I should move my ass and finally write that article about the pattern which I planned for some time. :)

I think the main problem with downstream only being able to implement Into<DerivationPath> is that it doesn't allow failure. Idk if that's a blocker though. Imo this trait is a fixme anyway and should be deprecated as soon as MSRV >= 1.34.0, at which point this wouldn't be a problem anymore.

nit: it's should be its