New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Library] enum Fallible on std #3395
Comments
This article you linked has a wrong understanding of unit type. The author thinks the unit type is of no value, hence the success case of A fact that the function returns already contains information. When the returned value is a unit type, it's simply that there's no additional information. But the information is already conveyed by the fact that it returns. So it's pretty obvious |
I don't think the article has any misconceptions about that, and the table is correct. But I also think that it is 8 years too late to be proposing something like this; the value of these kinds of types lies in their ubiquity and there is no way I think it would be a bad idea to add something like this to the prelude, and lose names like I think the only reasonable version of this would be if you had |
If anything, it'd make more sense to have |
unit contains one value, but in this case, a useless value |
8 years ago very few people knew Rust, I was just starting to learn programming with C and PHP I understand the difficulties in implementing, but to say that |
That wasn't directly aimed at you (obviously everyone has their own circumstances), but rather the proposal itself: Rust too stable now to be able to make foundational changes like this anymore. A proposal that tries to make
No, but the bar for getting things into the prelude is very high. So far the prelude has only changed once, for the 2021 edition, and even then most of the originally planned additions were cut before the release; and everything considered was already in |
@digama0 I meant that at that time Rust was irrelevant in a broader context (break changes weren't a problem like they are today) and influenced by few people, much less than today Well, it's the Haskell's lemma of not being popular, Rust is getting more bureaucratic, that was good, but now is difficulting its improvement |
Right. That's why such a change would have been okay then, but not now, even if the proposal were exactly the same. But even setting that aside, assuming we could magically solve the compatibility and ecosystem issues, I think there are other significant issues with the proposal like having Another way to put it: |
@digama0 why |
A monad is a type constructor |
I would say that
For example: Likewise, |
They aren't saying they have the same use case or that they are the same thing, they are saying that they have the same footprint and are interchangable. They both convey the same amount of information. The unit type conveys no extra information other than that exists, just like the None variant. You can convert any Result<T, ()> to an Option and vice versa without any data loss. Basically, Option could be a type alias for Result<T, ()>. |
how
Option
is equivalent toResult<T, ()>
,Fallible
is equivalent toResult<(), T>
https://datavirke.dk/posts/fallible-missing-rust-error-handling/
The text was updated successfully, but these errors were encountered: