Canonical struct naming, bump deps, removed unused deps

[virtualritz]

• Canonicalized various structs and enum variant names (Canonical struct naming #39).
• Bumped all dependencies to latest versions where possible (only wgpu 14->15 requires code changes and was held back).
• Removed all unused deps with cargo-machete and also applied cargo-sort to changed Cargo.tomls.
• Merged with latest master.

[CLAassistant]

All committers have signed the CLA.

[ytanimura]

Thank you for your pull request. It seems to be mostly fine. We will check properly and merge it within the next week.

[virtualritz]

I also saw the Included trait. From the trait bounds there and adhering to the naming convention for bool returning methods to start with is_ (e.g. Vec::is_empty()), I would suggest:

pub trait IsCurveIncluded<C: ParametricCurve> {
    /// Returns whether the curve `curve` lies on the surface `self`.
    fn is_curve_included(&self, curve: &C) -> bool;
}

[ytanimura]

I am not good at English by any means, but I still think is_curve_included is a bit ungrammatical. If I had to say, is_including? Anyway, we will check this pull request which we have received. If we continue this discussion, let's do it on the #39 side.

[ytanimura]

The format of knot_vec.rs is too different from the others, so I will revert it and pick up some corrections here.
I will write my views on your points for future reference.

"Examples" and "Panics"

It is standard in Rust documentation that the name of the section is "Examples" even if there is only one example.

Line breaks

It is standard markdown practice to insert line breaks before and after section headings. Let me put this one on hold. I personally prefer packed source files for the following reasons:

• It makes it easier to visually compare descriptions that are in contrast on distant lines.
• I can get some idea of the complexity of the source code from the number of lines.

In any case, if we are going to add line breaks, we should do so for all files.

Bullets

I believe that markdown bullets are a personal preference. Although asterisks is the official method of description used, there is no statement to the contrary that another method is deprecated, nor does it affect the output documentation. I have seen some say that asterisks are good because they are less often seen in English text, but I do not think that makes much sense since they will eventually appear in the source code. In the end, it is my personal preference, but since I am used to using it, there is no such thing as "I use a dash by mistake" but not "I use an asterisk by mistake".

-- edit in the next day --

Upon closer inspection of the old document, it does indeed appear to be a mixture of asterisks and dashes. My apologies. If we unify them in the future, I think dashes are the way to go.

[ytanimura]

We will revert the README for each crate. This is automatically generated by the readme-generator, so manual ad hoc rewriting will cause CI to fail.

[ytanimura]

We will also revert once about the main README. Please start another issue as it is the face of the crate. At least, please give me some reasons to change the "three elements". "Truck has Three concepts with initial 'T'." is so lame that it should be rewritten without any question?

[ytanimura]

Sorting in Cargo.toml can have certain meanings. For the top Cargo.toml, the truck series should come on top as the workspace, and example-pages-generator, for example, should come last. Some crates are split by function with a blank line for each function.

[ytanimura]

Thank you very much for your pull request. We merged the content in the title "Canonical struct naming, bump deps, removed unused deps." The following points will be reissued.

• README.md in the top page the top README.md improvement #43
• Comment format Comment Format #44
• README.md in the each crate README.md in each crate #45

I will summarize my opinions next week.

[virtualritz]

We will also revert once about the main README. Please start another issue as it is the face of the crate. At least, please give me some reasons to change the "three elements". "Truck has Three concepts with initial 'T'." is so lame that it should be rewritten without any question?

My main reason was that the README (and many parts of the documentation are a bit Anglish. I do not mean this in any way condescending.
Truck seems to be a very professional project from all I've seen looking at the source.
However, this professionalism is currently not well reflected in the README and many parts of the documentation because of the way the English language is used.

I understood that you started the three guiding principles with T to match with Truck but I did not find English words that do and sound natural for the message you tried to convey. So I did the next best thing and just made sure all three guiding principles at least start with the same letter (but not a T).
I'm happy to have anoter try if you tell me what is most important for you. My partner is an English native speaker and academic and she will proof read everything.

[ytanimura]

Thank you for your comment.

We understand that your pull request is well-intentioned. It may have be worded a little poorly. It was a change that needed more discussion than changes indicated in the title, so we have only reverted it for now. We are currently working on an improvement plan based on the suggestions we have received. We will publish them in a separate branch and would be glad to receive your feedback again.