Don't return TaffyResult when Taffy methods can't fail.

[gibbz00]

Fixes: #519.

Affected methods:

new_leaf, compute_layout, new_leaf_with_measure, new_with_children, remove, set_measure, add_child, set_children, child_count, children, layout, set_style, style, mark_dirty, dirty.

TODO:

Reduce implicit panicking possibilities. (See: #520 (comment))

• cargo gentest
• Update doc comments.
• Update RELEASES.md

Feedback wanted

As commented by @nicoburns: Many of the methods can still panic due to the frequent use of direct array indexing. But this shouldn't really be an issue since the keys themselves can't be created without them being registered by the Taffy instance, and removal takes ownership of the NodeIds. But this can unfortunately easily be bypassed by cloning them, or by creating them it from another Taffy instance.

So rather than creating checked/unchecked method equivalents, I would suggest removing these runtime panic possibilities by continuing to leverage Rust's build in memory safety and module scoping rules. This means passing borrowed NodeIds to methods that don't mutate any values, and removing the NodeId's Clone implementation etc.

[alice-i-cecile]

So rather than creating checked/unchecked method equivalents, I would suggest removing these runtime panic possibilities by continuing to leverage Rust's build in memory safety and module scoping rules. This means passing borrowed NodeIds to methods that don't mutate any values, and removing the NodeId's Clone implementation etc.

I really like this, but I'd prefer to do this in a separate PR to keep this reviewable.

[nicoburns]

I don’t think removing Clone from NodeId is going to work. We use that internally to store NodeId’s during layout (currently we also rely on NodeId being Copy, but that isn’t strictly necessary). And one would always be able to obtain duplicate NodeId’s by for example calling .parent() twice.