Ruben De Smet

> Well, that doesn't seem to be working any more. ```rust #![feature(use_extern_macros)] ``` (edit: Github was bugging, I didn't see the other comments and I cannot delete this one)

Secondly, note that ```rust #[async] for foo in rx.map_err(|_| -> io::Error { unreachable!() }) { } ``` works perfectly, but is quite painful to write. But that's not the real...

I've looked a bit around: [`work_items` is the generalization of issues/tasks/epics etc](https://docs.gitlab.com/ee/architecture/blueprints/work_items/): > Work Item types > > A set of predefined types for different categories of work items. Currently,...

> That is, is this issue actionable? I don't think it's currently actionable, no, from my very quick glance over the docs and some experimenting.

> Finally released Thanks for the work! I haven't noticed any issues with the patched version so far :)

@gferon we should install a CI step that checks whether the database update is a legitimate update.

> Looks like `regex` needs a more recent version of Rust. @rubdos how about bumping our MSRV to 1.65? Uh, do we actually need regex 1.10 for the new db...

> And I don't recall why sure why `strum` has this range for a version. Nevermind, that's because it's still on `0.x` :-)

We do not have a struct `Phone` nor a function `validate_str` that accepts random hexadecimal numbers. We should probably, however, document the panicking behaviour, and clarify that national numbers larger...

`NationalNumber::new` is not supposed to take untrusted data, and it certainly does not accept characters. The `PhoneNumber::from_str` implementation might parse into a number of more than 56 bits and feed...