`!` does not implement `Clone`

[Twey]

There is a trivial impl Clone for ! { fn clone(&self) -> Self { *self } }, but ! as it stands does not implement Clone. Maybe we should have that available? It does implement Copy.

Playground:
https://play.rust-lang.org/?gist=3a2e62b2ed08be07de7d84d8620c4b34&version=nightly

[retep998]

Another type that is Copy but not Clone despite Copy: Clone?! How are we able to keep repeating this mistake?

[durka]

This seems to be a known issue: #35121 (comment)

[abonander]

Why not have ! implement every trait automatically? It makes sense.

[cuviper]

Why not have ! implement every trait automatically?

It shouldn't implement Drop, at least, and I think associated types are a challenge too.

[codyps]

If ! can't be created, we can't ever drop it, right? Why would implementing Drop be an issue?

It shouldn't implement Drop, at least

Edit: (Drop is fairly special in how it is used, so it isn't clear how valuable having ! impl Drop would be, though).

[cuviper]

AIUI there are many assumptions that Copy and Drop are exclusive, and if you try to do this explicitly you get E0184. Maybe ! could be special in this regard.

It may also make things like needs_drop::<Result<(), !>>() return true, which seems weird.

[abonander]

It shouldn't implement Drop, at least, and I think associated types are a challenge too.

Drop, no. It's nearly useless in a generic context anyway. Associated types could be all set to ! themselves; any trait requirements on them would be satisfied transitively. Actually, what might be the problem are static methods:

pub trait MyTrait {
    // What to return here?
    // This applies to the `Default` trait too
    fn new_value() -> Self where Self: Sized;

    fn static_method() -> &'static str;
}

Of course, they could just be generated with unimplemented!() but that could get a little surprising in generic code.

[cuviper]

For the problem of associated types, I was thinking something like this:

trait Foo: Iterator<Item = i32> {}
trait Bar: Iterator<Item = &static str> {}

So would ! magically implement Foo and Bar? Or only Iterator<Item = !> set to itself, then fail to meet Item bounds that say otherwise? It will also need to not auto-implement IntoIterator, since the blanket implementation for T: Iterator already applies.

[abonander]

What I meant was that all associated types would be transitively set to !:

impl Iterator for ! {
    type Item = !;
    fn next(&mut self) -> Option<!> { ::core::intrinsics::unreachable() }
}

It will also need to not auto-implement IntoIterator, since the blanket implementation for T: Iterator already applies.

My thought was that the part of the compiler that answers the question, "Does [this type] implement [this trait]?" would just always say "Yes" for !. This does bring up the interesting question of user-defined impls for !, if they should override or what. I feel like this can be handled by specialization (having all auto-impls be marked as/considered to be default impl so user code can override them if coherence permits).

Also, my previous comment brings up an interesting question. Is !: Sized? Because MyTrait::new_value() would automatically be excluded if it is not.

[cuviper]

If it weren't Sized, then ! couldn't be used in Option, Result, etc., let alone Copy or Clone.

How about associated consts? That's similar to your static_method(), but we can't write unreachable().

[abonander]

Good question. The answer that comes to mind is "just have it be an error to access them" but that doesn't help much in a generic context because then you could have generic code that compiles just fine but if you introduce ! as a type parameter you're suddenly getting errors from inside that generic boundary. It would be as unhelpful as Error originates in a macro outside this crate.

I think associated consts should just disqualify traits from this auto-impl since there's no sane value to give them. It wouldn't diminish the utility of the feature all that much.

[soltanmm]

How would ! implementing all traits interact with negative traits? Would it be the sole type simultaneously implementing Trait and !Trait for all traits? I can imagine this leading the compiler to automatically propagate ! during type inference and allowing problematic code to compile, leaving problems undiscoverable until runtime when everything panics on empty implementations (though I haven't taken the time to think of any specific problematic weaponizations of the feature if they're possible).

[codyps]

@soltanmm the compiler is the one emitting that code (dummy ! impls). All it has to do is not emit the code and give an error instead. Ideally, we'd have a mechanism other than actual dummy impls for !).

[durka]

Stepping back, what is the advantage of having ! pretend to implement every trait? Seems like it comes with a host of tricky complications.

…

On Thu, Jul 20, 2017 at 1:53 PM, Cody Schafer ***@***.***> wrote: @soltanmm <https://github.com/soltanmm> the compiler is the one emitting that code (dummy ! impls). All it has to do is not emit it and give an error instead. Ideally, we'd have a mechanism other than actual dummy impls for !). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#43296 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAC3n2dcAipXUxUJLCVP7atZIclaNuDRks5sP5QBgaJpZM4OacID> .