Named impls

[SoniEx2]

As of right now all impls are anonymous and public. I propose named impls and named public impls:

impl X as Y for Z for a private impl

pub impl X as Y for Z for a public impl

This is similar to how traits currently work: you need to import them to use them.

With a non-pub impl, you can use it within your module. With a pub impl, you can use it outside your module. In any case, you need to explicitly import it with use. You can also import them from an external crate, but it follows the same rules - only available where you use them.

Later we could also add !pub impl Y for Z if we want crate-wide, anonymous impls. (Sadly, since they're already public by default, we can't have impl Y for Z and pub impl Y for Z, except maybe in Rust 2.0.)

[pnkfelix]

Rust used to have named impls. (Ancient history; I'm having trouble even finding a proper record of when they were removed.)

My memory is that they were removed, at least in part, because one could express such functionality via traits: instead of naming an impl and exporting it, you would instead define a trait, impl it, and export the trait (and then clients who wanted that implementation code would import the trait).

You yourself even note that "this is similar to how traits currently work."

Can you elaborate on what the advantage(s) are of your proposal over the status quo of using traits to express this?

[SoniEx2]

When crate A defines struct X, crate B defines trait Y, crate C defines impl Z as X for Y, you can use Z if you don't wanna make your own newtype struct and impl and so on.

They're contextual impls, just like traits are contextual.

[pnkfelix]

@SoniEx2 Can't one run into coherence issues then? I.e. you have crate C adding its own named impl (of trait) Y for (struct) X, but then crate D can add its own conflicting impl of that same trait for the same struct?

A typical example of where incoherence like that can cause a problem: Hashtables. Lets say the trait is Hash. If two different crates implement Hash in different ways for the same type, then passing a hashtable around between the two crates is going to cause them to use inconsistent hash-values when attempting to lookup entries for the same key.

[pnkfelix]

To be clear: I do not want to shoot down new ideas.

I am just trying to remember, and document, the reasons for why this feature was removed in the first place, which is what is pushing me to construct examples such as the aforementioned incoherent hashtable...

[SoniEx2]

The named impl is part of the (generic) type.

HashMap<usize(X)> is different from HashMap<usize(Y)>.

It's similar to newtype structs in that aspect.

[Centril]

Relevant: https://internals.rust-lang.org/t/looking-for-rfc-coauthors-on-named-impls/6275

[est31]

This seems some kind of anonymous newtypes like proposal. I think its best solved via delegation of implementation instead: #1406

[SoniEx2]

Keep in mind you'd be able to use named impls for the same type from multiple different crates. This means you don't have to juggle 3 (or more) types around.

use a::Base;
use b::Append;
use c::Prepend;

let x = Base::new();
x.append(0);
x.prepend(1);

[SoniEx2]

btw: it's X as (Y for Z) not (X as Y) for Z (altho this can be argued)

[porky11]

Will this allow something like this:

// crate A
trait A {…}

// crate B
struct B;

//crate C
use A::A;
use B::B;

// following not possible

trait C {…}

impl<T> A for T where T: C {…}

impl C for B  {…}

// the proposed syntax, does the same, but would work

impl A as C for B {…}

Did I understand it correctly?
So I could use something of type B as A when I use C

[SoniEx2]

eh maybe we should just go for impl C = A for B tbh, way less confusing >.<

[durka]

@pnkfelix isn't the idea with named impls that coherence issues all go away because you choose which impls to use, eliminating any ambiguity? So I guess a coherence error would come up when you try to use two conflicting impls, rather than when writing them.

[SoniEx2]

I think there should be an explicit syntax for choosing named impls? It should be implicit by default, except when you use two conflicting impls, in which case you should use explicit ones.

[pnkfelix]

@durka I don't know how to answer your question, because @SoniEx2 is adding information to their presentation of named impls that does not match my mental model of them.

E.g. as soon as the choice of named impl for Hash shows up in one's HashMap type, then that to me looks like a newtype instance (as noted by @est31), not a named impl as I understand it.

Except that @SoniEx2 later claimed that one isn't juggling types.

So I'm just going to say "I don't understand this proposal" and not attempt to suggest further interpretations of it.