Stream: project-error-handling

Topic: Specialization


view this post on Zulip Jeremiah Senkpiel (Nov 26 2020 at 17:48):

Btw, should this group be invested in moving specialization along at all?

I ask particularly because of the whole "<anyhow> can't implement StdError because it would conflict between From<StdError> and From<Self>"?

view this post on Zulip Jeremiah Senkpiel (Nov 26 2020 at 17:48):

Unless that is somehow planned to be solved somehow else? (Although I can't imagine how...)

view this post on Zulip oliver (Nov 26 2020 at 17:52):

as long as they are part of the same specialization family?

view this post on Zulip Jeremiah Senkpiel (Nov 26 2020 at 17:55):

Not sure I follow - my understanding is that what would be desirable here would be impl StdError for Self and then i.e. From<T: StdError NOT Self>?

view this post on Zulip Jeremiah Senkpiel (Nov 26 2020 at 17:56):

i.e. negative bounds, or a special self exclusion bound

view this post on Zulip oliver (Nov 26 2020 at 18:11):

from what I recall there is resistance to having conditional negative impls

view this post on Zulip oliver (Nov 26 2020 at 18:12):

though this might be added for Error return traces as a missing feature

view this post on Zulip oliver (Nov 26 2020 at 18:14):

I think that negative impl is intended to be impl !StdErr .. rather than allowing for opt-in for various traits overlapping with conditional impls

view this post on Zulip oliver (Nov 26 2020 at 18:24):

https://github.com/rust-lang/rust/issues/23072#issuecomment-85960388

view this post on Zulip Jeremiah Senkpiel (Nov 26 2020 at 19:32):

Ah, hmm, that seems like a different feature than I though. Perhaps there isn't any named/rfc'd feature for this, but I'm thinking specifically about "negative trait bounds for generics" (even if only for Self) to get around conflicting with blanket impls (e.g. From<T> for T).

view this post on Zulip oliver (Nov 26 2020 at 19:49):

I expect this will need to be a new feature proposal

view this post on Zulip oliver (Nov 26 2020 at 19:54):

tho negative trait bounds on generics isn't in my registers

view this post on Zulip Jeremiah Senkpiel (Nov 26 2020 at 20:11):

@Yoshua Wuyts We've talked about this, do you have any recollection of previous conversations about this "negative trait bounds" thing?

view this post on Zulip pachi (Nov 26 2020 at 20:28):

@Jeremiah Senkpiel maybe you could try in #wg-traits as they're implementing the next generation torchwood and trait solving infrastructure (called chalk) and face those problems. Of course, #t-lang is also related to it.

view this post on Zulip Yoshua Wuyts (Nov 26 2020 at 23:29):

@Jeremiah Senkpiel enabling negative trait bounds to count towards coherence is one of the requirements to enable async fn main.

We want to implement impl<F, T> Termination for F where F: Future<Output = T>, T: Termination. Which requires we declare that () will never implement Future.

view this post on Zulip Yoshua Wuyts (Nov 26 2020 at 23:35):

The reason for that is that Termination is defined in libstd, while both Future and unit are defined in libcore.

Termination is implemented for unit. So in order for the generic impl to be valid we need to declare that unit will never implement Future, making it so the generic impl will never accidentally conflict in the future.

view this post on Zulip Yoshua Wuyts (Nov 26 2020 at 23:36):

I don't know how relevant it is to what's being discussed here; but I think this is what you may be remembering from convos we've had in the past.

view this post on Zulip Jane Lusby (Nov 30 2020 at 17:59):

Yoshua Wuyts said:

The reason for that is that Termination is defined in libstd, while both Future and unit are defined in libcore.

Termination is implemented for unit. So in order for the generic impl to be valid we need to declare that unit will never implement Future, making it so the generic impl will never accidentally conflict in the future.

this seems like it might be solved by merging core and std

view this post on Zulip Jane Lusby (Nov 30 2020 at 17:59):

if its an orphan rule issue

view this post on Zulip Jane Lusby (Nov 30 2020 at 17:59):

that said

view this post on Zulip Jane Lusby (Nov 30 2020 at 18:00):

the issue with impling Error for Box<dyn Error> and anyhow::Error will probably require a significant amount of work

view this post on Zulip Jane Lusby (Nov 30 2020 at 18:00):

my understanding is that it requires that chalk implements the lattice rule

view this post on Zulip Jane Lusby (Nov 30 2020 at 18:00):

which isn't planned afaik

view this post on Zulip Jane Lusby (Nov 30 2020 at 18:00):

we should probably double check with @WG-traits

view this post on Zulip oliver (Nov 30 2020 at 18:01):

what is the lattice rule again? sounds familiar :thinking:

view this post on Zulip Jane Lusby (Nov 30 2020 at 18:01):

let me grab a link rq

view this post on Zulip Jane Lusby (Nov 30 2020 at 18:02):

https://github.com/rust-lang/rfcs/blob/master/text/1210-impl-specialization.md#the-lattice-rule

view this post on Zulip oliver (Nov 30 2020 at 19:33):

nice, I have references to semi-lattices and consistency types

view this post on Zulip Joshua Nelson (Nov 30 2020 at 20:49):

Jane Lusby said:

Yoshua Wuyts said:

The reason for that is that Termination is defined in libstd, while both Future and unit are defined in libcore.

Termination is implemented for unit. So in order for the generic impl to be valid we need to declare that unit will never implement Future, making it so the generic impl will never accidentally conflict in the future.

this seems like it might be solved by merging core and std

FWIW Pattern gets around this for char and FnOnce with 'compiler magic': https://doc.rust-lang.org/nightly/src/core/ops/function.rs.html#145

view this post on Zulip Jane Lusby (Nov 30 2020 at 20:50):

:grimacing:

view this post on Zulip scottmcm (Nov 30 2020 at 20:58):

Another option might be to make coherence take into account https://doc.rust-lang.org/nightly/unstable-book/language-features/negative-impls.html

And to add an impl !Future for () {}

(That seems like it'd be a bit more elegant of a way to handle the pattern problem, too. Would at least be an interesting separate feature flag to have available to play with in core/std and see if we'd want to make it available more generally.)

view this post on Zulip Jane Lusby (Nov 30 2020 at 20:59):

my understanding was that negative impls somehow play poorly with exhaustiveness and how solvable the trait system is

view this post on Zulip scottmcm (Nov 30 2020 at 21:01):

Sounds like a niko question, since I really don't understand how all that stuff works.

view this post on Zulip Yoshua Wuyts (Dec 01 2020 at 11:33):

@Joshua Nelson oh my


Last updated: Jan 26 2022 at 14:02 UTC