difftastic doesn't show whitespace or formatting changes

Printers are way worse

Lol

Very cool project!

It's interesting to see how different DNS providers cap the maximum TTL.

Google uses 21600s

Quad9 uses 43200s

Cloudflare does not cap at all!

And my personal unbound uses 86400s (which is the default)

For sorting sequential fields you can chain comparisons with .then():

    struct Date {
        year: u32,
        month: u32,
        day: u32,
    }
    
    let mut vec: Vec<Date> = Vec::new();
    
    vec.sort_by(|a,b| {
       a.year.cmp(&b.year)
        .then(a.month.cmp(&b.month))
        .then(a.day.cmp(&b.day))
    });

Alternatively you can derive PartialEq, PartialOrd, Eq and Ord for your struct, which will produce a lexicographic ordering based on the top-to-bottom declaration order of the struct's members:

    #[derive(PartialEq, PartialOrd, Eq, Ord)]
    struct Date {
        year: u32,
        month: u32,
        day: u32,
    }

Or you can use sort_by_key and extract the relevant sorting key as a tuple (or any other Ord structure) e.g.

    vec.sort_by_key(|d| (d.year, d.month, d.day))

sort_by is more flexible as it works fine with borrows, but when sorting on a series of integer values or references sort_by_key is great.

> Alternatively you can derive PartialCmp for your struct, which will produce a lexicographic ordering based on the top-to-bottom declaration order of the struct's members:

Do you mean PartialOrd? partial_cmp is the method. And `sort` requires absolute ordering (Ord) not just partial.

I quite like this tuple approach.

And yeah, I meant Ord (and the required other Traits), I edited my post. Thanks for pointing this out.

Rust has a `usize` which is 32 or 64 bits depending on the platform and also serves as the native index type for arrays and such.

Yeah, that makes sense because you need some type to span the address space and that depends on the size of the address space. That is what int is used for in go, though why they chose signed rather than unsigned is confusing. unsigned you would never have to do negative bounds checks and you can prove a lot of other useful things if you know your index is always positive.

I don't know how go does it, but in some languages negative indices count backwards from the rear end. E.G. myarr[-1] == myarr[myarr.length-1].

Does it cover the Parker Square?