chrono not chorno

chrono not chorno

i'm offended. Ubuntu and Manjaro are the 2 distros i absolutely refuse to have on my device. the closest distro to Ubuntu that is actually great is Mint.

@@bocchitherock-ob2bl why

@@kchaitanya39 Ubuntu: 1st reason is Unity, 2nd is sudo apt install firefox. Manjaro: the devs don't know what they are doing, they recommend not using the aur on manjaro (which is my main reason for using arch) but still made pamac and ddos'ed the aur servers 2 times.

Btw, i use arch

@@bocchitherock-ob2bl I used Ubuntu exclusively for 13 years and then switch to the next meme distro Manjaro. I had enough after 1.5 years.

I got you!

I actually find it quite funny 😅

as an arch user, they do not need a user agent to identify us

@@motozirillo true

It's not a typo. It's the Ukrainian equivalent of the n-word.

its not delivery, its dechorno

Or was it...

I am the great chornolio! I need TZ for my crate hole! Heh! Heh! Mmm.

@@steamer2k319 haha, a classic!

Thanks for watching Luis! :)

What are stdlib naming conventions?

@@adityanithariya At least for Iterators, it is just the name of the iterator like: Map, Slice or Filter (check it out)

Imagine if there was a trait A and type TA in crate ca, crates cb and cc both have different implementations of A for TA. And if this issue only pops up when all 3 crates are used together, it will be a pain

@@InfiniteCoder01 Ohhhh, I see, I was only thinking from a final user's prespective (i.e. someone making an app, not someone making a crate). Thanks!

But don't you think doing it for tuple is bit explicit, and not that necessary, as it's providing those features in other forms?

@@adityanithariya first I did a simple function that created a new error with the text in the argument. I found that not very "iconic" but wanted to use "into()" or "from()". That was possible by doing the derived struct (and using same all over the place instead of "Error"). But doing an extension trait and staying with the "Error" type would be even more "iconic", if that is possible,

@@michaelschnell5633 Yeah, that would be modular and more friendly!

@@adityanithariya an even more obvious example: I can do: let i:i32 = 1; let f: f64 = x.into(); I even can do fn ff(f: F) -> f64{ f.into() } let i:i32 = 1; let f = ff(i); and have the compiler infer the appropriate "From" when calling the function with whatever type !!!!. but I can't do let i:i64 = 1; let f: f64 = x.into(); -> the trait `From` is not implemented for `f64`, which is required by `i64: Into` this is obviously OK, as it would loose accuracy. But what if I in my project know that the all i64 will be small enough, I don't care about loosing accuracy or want a panic if the u64 is too big ? How could I implement a custom From for f64 ? I am not allowed to do impl From for f64{}; even though the lack of same exactly is the error message above :( (hence no ambiguity)

@@adityanithariya A way to implement a default filed for structs (the fields and methods of which would be usable as fields and methods of the main struct) could be to define same by an appropriate #[.... attribute to such field, By that there would be no danger to break any existing code.

I tried to change my user agent to "Arch Linux" too and it didn't work, which makes sense, but I was lowkey hoping he'd be that cheeky

You can only use functionality from the extension trait if you import it. And rust won't let you import two traits with the same name. But you can import those traits using different names, which will cause ambiguity. Then you'll need to specify, function from which trait to use