this post was submitted on 26 Apr 2024
8 points (100.0% liked)

Learning Rust and Lemmy

391 readers
1 users here now

Welcome

A collaborative space for people to work together on learning Rust, learning about the Lemmy code base, discussing whatever confusions or difficulties we're having in these endeavours, and solving problems, including, hopefully, some contributions back to the Lemmy code base.

Rules TL;DR: Be nice, constructive, and focus on learning and working together on understanding Rust and Lemmy.


Running Projects


Policies and Purposes

  1. This is a place to learn and work together.
  2. Questions and curiosity is welcome and encouraged.
  3. This isn't a technical support community. Those with technical knowledge and experienced aren't obliged to help, though such is very welcome. This is closer to a library of study groups than stackoverflow. Though, forming a repository of useful information would be a good side effect.
  4. This isn't an issue tracker for Lemmy (or Rust) or a place for suggestions. Instead, it's where the nature of an issue, what possible solutions might exist and how they could be or were implemented can be discussed, or, where the means by which a particular suggestion could be implemented is discussed.

See also:

Rules

  1. Lemmy.ml rule 2 applies strongly: "Be respectful, even when disagreeing. Everyone should feel welcome" (see Dessalines's post). This is a constructive space.
  2. Don't demean, intimidate or do anything that isn't constructive and encouraging to anyone trying to learn or understand. People should feel free to ask questions, be curious, and fill their gaps knowledge and understanding.
  3. Posts and comments should be (more or less) within scope (on which see Policies and Purposes above).
  4. See the Lemmy Code of Conduct
  5. Where applicable, rules should be interpreted in light of the Policies and Purposes.

Relevant links and Related Communities


Thumbnail and banner generated by ChatGPT.

founded 9 months ago
MODERATORS
 

Intro

I'm not on top of traits or generics but found myself looking some of them up anyhow, and came across the Sum trait.

Here is the Std Lib documentation on Sum (I believe).

And I guess all of the generics and/or type logic and how they interoperate has thrown me for a bit of a spin ... so I thought I'd put my thoughts here. Maybe I'll work things out in writing it or maybe someone here can help me/us out?

A bit long ... sorry


Trait Definition

From the docs and source, here is the trait's signature:

// core::iter::Sum
pub trait Sum<A = Self>: Sized {
    // Required method
    fn sum<I: Iterator<Item = A>>(iter: I) -> Self;
}

First thoughts: Defined on elements not iterators?

  • The part that confused me at first was what Self is actually. Naively, I imagined it was referring to the iterator (or type that'd implemented Iterator) ... but that clearly can't be true because the return type is Self.
  • So ... Sum is implemented not on any collection but on the element type?!
  • If so, why not rely on the Add Trait at the element level, which is responsible for the addition operator (see docs here)?

Kinda seems so?

  • So, in trying to understand this, I thought I'd look at the source of Iterator::sum() first figuring that it'd be the main implementation.
  • This is the sum you'd be calling in something like vec![1, 2, 3].into_iter().sum() to get 6.
core::iter::Iterator::sum
fn sum<S>(self) -> S
where
    Self: Sized,
    S: Sum<Self::Item>,
{
    Sum::sum(self)
}
  • Ok, so the call of Sum::sum(self) clearly indicates that this is not where Sum is defined (instead it must be in Sum::sum() somehow).
  • Moreover, self is being passed into Sum::sum(), withself being the Iterator here ... which means there's no method being called on Iterator itself but something from another module.
  • Additionally, this method is bound by the generic <S> which is defined in the where clause as Sum<Self::Item> ... which ... wait WTF is going on?
    • So this method (Iterator::sum()) must return a type that has implemented the trait Sum??
    • If that's correct, then that confirms my suspicion that Sum is implemented on the elements of an iterator (where I'm sure those comfortable with the generics syntax of the definition above are yelling YES!! OF course!!)
    • That's because the return type of sum() would generally have to be the same type as the summed elements, so S is both the type of the elements in the iterator and the return type of sum. All good.
    • And indeed, in the definition of the type alias S we've got Sum<Self::Item> which binds the return type of Iterator::sum() to the type of the iterator's elements (ie Self::Item)
      • Self::Item is technically the Item type of the Iterator which can, AFAIU, be defined as distinct from the type of the elements of the collection from which the iterator is derived but that's another story.

Back to the beginning

  • So back to trying to understand the definition of core::iter::Sum (which I believe is the definition of the trait):
// core::iter::Sum
pub trait Sum<A = Self>: Sized {
    // Required method
    fn sum<I: Iterator<Item = A>>(iter: I) -> Self;
}
  • The trait itself is bound to Sized. I don't know the details around Sized (see docs here and The book, ch 19.4 here) but it seems fundamental likely that it applies to vectors and the like.
  • The generic A = Self and its occurrences in the generics for the sum() function and its return type ... are a lot:
    • AFAIU, Self, ie the type on Sum is implemented for, must be the Item type for the Iterator that will be passed into the sum method.
    • But it must also be the return type of sum() ... which makes sense.
  • So the confusing part here then is the generic type of the sum() method: <I: Iterator<Item = A>>.
    • Remember, A = Self, so it's really <I: Iterator<Item = Self>> (right?)
    • This generic type is any Iterator whose Item (ie, the type that is returned each iteration) is the same type as Self.
  • Which means that if I want to sum a vector if i32 numbers, I'd have to make sure I've implemented Sum not on Vec but on i32 and defined it as a method that takes any iterator of i32 (ie Self) elements to then return an i32 element.
  • Ok ....

Confirmation

  • We can look at the implementors of core::iter::Sum ( see docs here) and check the source for the i32 implementation ...
  • Which gives us this source code:
integer_sum_product! { i8 i16 i32 i64 i128 isize u8 u16 u32 u64 u128 usize }
macro_rules! integer_sum_product {
    (@impls $zero:expr, $one:expr, #[$attr:meta], $($a:ty)*) => ($(
        #[$attr]
        impl Sum for $a {
            fn sum<I: Iterator<Item=Self>>(iter: I) -> Self {
                iter.fold(
                    $zero,
                    #[rustc_inherit_overflow_checks]
                    |a, b| a + b,
                )
            }
        }
  • which ... uses fold() (basically reduce but with an initial value) and plain addition in the anonymous/closure function |a, b| a + b. What!?

Why? How?

  • Ok that was a long way to go to find the addition operator at the bottom of the heap of traits!

  • Hopefully I've grasped the mechanics?!

  • I'm not quite clear on why it's build this way. I'm guessing there's some flexibility baked into the way that the relevant implementation of Sum depends on the element type, which can be flexibly defined as the Item type of an Iterator independently of the type of the collection's elements. That is, an iterator can utilise a type different from the actual elements of a collection and then rely on its particular implementation of sum. And then this can be independent from Add.

  • But that feels like a lot of obscure flexibility for a pretty basic operation, no?

  • For example, this code doesn't compile because a type needs to be specified, presumably type inference gets lost amongst all the generics?

// doesn't compile
let x = vec![1i32, 2, 3].into_iter().sum();

// These do compile
let x2 = vec![1i32, 2, 3].into_iter().sum::<i32>();  // turbofish!!
let x3: i32 = vec![1i32, 2, 3].into_iter().sum();

  • Design choices aside ...
  • I'm still unclear as to how Iterator::sum() works
fn sum<S>(self) -> S
where
    Self: Sized,
    S: Sum<Self::Item>,
{
    Sum::sum(self)
}
  • How does Sum::sum(self) work!?
  • self is the Iterator (so vec![1i32, 2, 3].iter()).
  • And Sum::sum() is the essential trait addressed above.
  • How does rust go from a call of a trait's method to using the actual implementation on the specific type? I guess I hadn't really thought about it, but it makes sense and it's what all those Selfs are for.
  • In this case though, it's rather confusing that the relevant implementation isn't on the type of self, but because of the definition of Sum, the implementation is on the type of the elements (or Item specifically) of self. Sighs

Thoughts??

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 2 points 7 months ago

You are a fucking hero my friend!! Thanks so much!!

Thanks for clarifying the macro ... I didn't understand what was going on there, but it makes sense that that's where the zero comes from.

And yea, as for the generics ... I didn't know about the default value (I was clearly reaching beyond what I could grasp!) ... thanks again!!

Quite confusingly, the two =s have very different meaning here. The Item = A syntax just says that the iterator’s item type, which is set as the trait’s associated type, should be A. So, you could read this as “I should implement the Iterator trait, and the Item associated type of this implementation should be A”.

However, A = Self does not actually mean any requirement of A. Instead, it means that Self is the default value of A: that is, you can do impl Sum for i32 and then you will have Self equal to i32 and A equal to i64, but you can also do impl Sum for i32 and it will essentially be a shorthand for impl Sum for i32, giving you both Self and A equal to i32.