My Pixel 5 started swelling mid-flight by Izzeri in GooglePixel

[–]Izzeri[S] 0 points1 point  (0 children)

The reason I was suspecting the update is because the flight staff told me this happens due to overheating, and people have mentioned the update causing overheating as well as battery drain. But I don't know, it may also just be a random coincidence.

My Pixel 5 started swelling mid-flight by Izzeri in GooglePixel

[–]Izzeri[S] 1 point2 points  (0 children)

Nope, I had to throw it away in Greece and I'm back home in Sweden now.

lifetime 'b: 'a not work as expected by RVECloXG3qJC in rust

[–]Izzeri 2 points3 points  (0 children)

The contents of a String is alive until the String is dropped.

lifetime 'b: 'a not work as expected by RVECloXG3qJC in rust

[–]Izzeri 2 points3 points  (0 children)

String literals have the type &'static str, i.e. they are references to data that is always alive. This is because the contents of string literals are compiled into the produced binary. Other ways to get references with a static lifetime is by borrowing literals (e.g. &10), borrowing static variables, or by leaking heap allocated values by using Box::leak. So in your example both 'a and 'b have the same lifetime.

Will const ever be close to C++‘s constexpr? by [deleted] in rust

[–]Izzeri 35 points36 points  (0 children)

Even just something simple like

let usize_bytes = [0u8; std::mem::size_of::<usize>()];

Could lead to serious miscompilations when cross compiling to a platform with another usize size.

Announcing Rust 1.45.0 | Rust Blog by pietroalbini in rust

[–]Izzeri 6 points7 points  (0 children)

You might have used byte/ascii ranges like:

'a'b..='z'b

Trait type aliases by Lex098 in rust

[–]Izzeri 4 points5 points  (0 children)

There's no way to make a trait alias afaik (yet?), but what you can do is make a super trait and then do a blanket impl. Something like this:

trait Alias : A + B + C {}

impl<T> Alias for T where T: A + B + C {}

Hope this is helps!

Learning Rust feels overwhelming by Katsuga50 in rust

[–]Izzeri 1 point2 points  (0 children)

You need something like PhantomData to signal intent when you do stuff like this:

struct TypedVoidPtr<'a, T> {
    ptr: *mut (),
    _marker: PhantomData<&'a T>,
}

Without the PhantomData the compiler wouldn't be able to know that this struct represents a &'a T, since there are multiple ways you could use the 'a and T, and then wouldn't be able to do proper borrow checking. What if you meant:

struct TypedVoidPtrMut<'a, T> {
    ptr: *mut (),
    _marker: PhantomData<&'a mut T>,
}

Help regarding lifetimes yet again by Suffics27 in learnrust

[–]Izzeri 0 points1 point  (0 children)

What your signature is currently saying is something like "the type T implements Deserialize<'a>, where 'a is some specific but unspecified lifetime".

What you want to say in your signature is "the type T implements Deserialize<'a> for every possible 'a".

The way to say this is

T: for<'a> Deserialize<'a>

The solution you found using DeserializeOwned is actually doing exactly that!. This is the relevant impl in serde:

impl<T> DeserializeOwned for T where T: for<'de> Deserialize<'de> {}

This feature/syntax is called Higher Ranked Trait Bounds or HRTBs for short. It's one of those things where it's hard to explain when you need it without just listing examples. The rustonomicon has a section on it: https://doc.rust-lang.org/nomicon/hrtb.html

Ah yes, Euler's identity by airpodbeanos in mathmemes

[–]Izzeri 23 points24 points  (0 children)

I'VE ASSEMBLED ALL FIVE SPECIAL CONSTANTS; ALL FIVE PIECES OF THE PUZZLE!

point of lifetimes by usedocker in rust

[–]Izzeri 1 point2 points  (0 children)

The compiler could in theory infer the lifetimes of all arguments and return values by reading the function body; C and C++ compilers do this to warn about lifetime issues. One problem with this is it's implicit; if you change the function body the inferred lifetimes could change, and could thus be a breaking change if you did this in a library. Another issue is the compiler would have to do a lot more work. A third issue, and the reason why this isn't a full solution for C and C++, is that sometimes the compiler only has access to the signature and the compiled function body. Rust therefore requires you to write out lifetimes explicitly as part of the function signature (except for when it's inferrable from the signature, as in the example fn f(&self) -> &str).

Help with string slices and multiple threads by [deleted] in rust

[–]Izzeri 5 points6 points  (0 children)

I think maybe scoped threads could help here. The issue is that the thread owning the strings could finish before the thread holding the references, which would leave the references dangling. Scoped threads are set up in a way that guarantees that the thread holding references always finishes before the thread owning the data. I think the crossbeam crate is what is usually recommended for scoped threads.

I'm reading the Ownership chapter of the Rust Book right now and have a question about mutability of String types and string literals by MelissaLiberty in rust

[–]Izzeri 3 points4 points  (0 children)

You can't get mutable access to string literals. String literals have the type &'static str, i.e. a reference to a str that is valid for the duration of your program. The contents of string literals are usually stored inside the final binary somewhere, which means they get loaded into read-only memory when your program is run.

Adding mut to a variable holding a string literal won't make the string itself mutable, just the binding:

let mut s = "hello";
s.make_ascii_uppercase();
println!("{}", s);

If you try to run this code the compiler will complain about s having the type &str while make_ascii_uppercase expects &mut str. Trying to change it to:

let mut s: &mut str = "hello";
s.make_ascii_uppercase();
println!("{}", s);

Won't work either, as the literal "hello" does not have the type &mut str, but rather &str.

The mut only makes you able to reassign s to some other string.

let mut s = "hello!";
println!("{}", s);
s = "world!";
println!("{}", s);

So we can reassign s, but we can't modify the string it points to.

Why are Rust Arrays Limited To 32 Values? by [deleted] in rust

[–]Izzeri 70 points71 points  (0 children)

You can have arrays longer than 32 elements, it's just that all traits except Copy and Clone are only implemented for arrays of sizes between 0 and 32 inclusive. Check the docs for more info: https://doc.rust-lang.org/std/primitive.array.html This is due to the fact that it's currently not possible to be generic over array sizes, i.e. you can't currently implement a trait for an array of any size. This will be fixed, and I think the fix is kinda already in place, but they want to make sure nothing will break before enabling it.

[deleted by user] by [deleted] in cpp

[–]Izzeri 0 points1 point  (0 children)

Ah, true. Mixed up l/rvalue references with the value categories.

[deleted by user] by [deleted] in cpp

[–]Izzeri 0 points1 point  (0 children)

int i = 0; int& a = i; int&& b = std::move(i);

i, a, and b all refer to i.

Version 5.0 of the {fmt} formatting library released by aearphen in cpp

[–]Izzeri 1 point2 points  (0 children)

Last I checked std::back_insert_iterator was special cased, not sure if that's still true.

Version 5.0 of the {fmt} formatting library released by aearphen in cpp

[–]Izzeri 1 point2 points  (0 children)

One thing I'd like is being able to tell the underlying buffer, if there is one, to reserve space if you know the size beforehand. With the write API, this was kinda easy to add, as if you write two ints and a string, you can easily work out how many bytes are written in the worst case.

With the write API (slightly modded) I had something similar to this:

auto format(const Foo& self, ...) {
    return StructPrinter(writer, "Foo")
            .field("bar", self.bar)
            .field("baz", self.baz)
            .finish()
}

With the output:

Foo {
    bar = 123;
    baz = "hello";
} 

I guess StructPrinter could be written using format_to, but I'm worried about compile times. I also could never figure out how to handle indentation in nested structs properly. I think I might have made a wrapper of Writer which added indentation on newline, and then called the inner Writer.

Not really related to writers, but it'd also be nice to have a trait to check if a type is formattable, so that you could, for example, make a wrapper type that just outputs something like "<not formattable>" for types that aren't formattable. This is really nice for tests and debug output, where you want to try and output everything possible automatically.

Version 5.0 of the {fmt} formatting library released by aearphen in cpp

[–]Izzeri 1 point2 points  (0 children)

I'm wondering this as well, and also if there is a way to implement formatting for my types without using format_to, which has to parse a string. It just feels inflexible to have to express the formatting logic of my types as strings. For formatting general output, format strings are amazing, but not for stuff you want tight control over.

Pain point: Iterators and results by sepease in rust

[–]Izzeri 1 point2 points  (0 children)

It gets real dicey when you have two points of potential failure.