[6equj5]

To me, the point of it is just to be more explicit and ease maintenance, like `typedef int meters_t`, but more extensible. Compare `int foo_len` to `meters_t foo_len`.

Explicitness: Consider the ambiguousness of `int foo_len` when you're swapping between meters and feet (but use `int` for both).

Ease maintenance: If you want to change the type you use to represent meters (say from `int` to `size_t`, since it might be wise to make it unsigned), compare going through the code and changing each meter-related instance of `int` vs. just changing the `meters_t` struct declaration.

More extensible: Compared to `typedef int meters_t`, using a struct is useful if you ever have to add to the struct. (Maybe a second numeric member representing the conversion to some other unit of length or something.)

For "meters", this doesn't really apply, but using a struct also prevents you from accidentally trying to do math with numeric types that you shouldn't do math with (like ID numbers or something): https://stackoverflow.com/a/18876104/9959012

Also, you probably shouldn't use `_t` at the end since that should be reserved by the C standard and by POSIX: https://stackoverflow.com/a/231807/9959012

[hot_gril]

Where I work, the C++ style guide explicitly says not to alias int types like this cause it becomes annoying for others to keep looking up what each thing really is, and probably YAGNI. I agree with that recommendation.

Any int variable storing meters is probably called "meters" already.