- Amsterdam, Netherlands
- https://cessen.com
-
Animator, rigger, and software developer. Currently working at the Blender Institute as a developer on Blender's animation system.
Been using Blender since 1998, and worked on Big Buck Bunny and Sintel (two of Blender's open movie projects).
- Joined on
2003-03-21 -
-
Ah, thanks! Yeah, that makes sense. So then the semantics around the call in various situations would be like this(?):
// `s` is either a new string "hello" or a full copy of the string…It looks like I can get rid of Result(V &&value) : data{std::move(value)} {}, at least.
On Err, however, if I remove Result(Err<E> &error) : data{error} {} then the unit tests fail to…
Ah, and so to be clear: I still personally prefer Err, but I'm happy to change it if others prefer Error or if you feel strongly about it.
Ah, good point. In an earlier iteration I just stored E directly (not wrapped in Err), so this was needed to address the corner case of V and E being the same type. But now with E…
That's fair. I guess it comes down to how namespaces are used.
I'm again coming from a Rust perspective where modules (more-or-less the equivalent of namespaces in C++ in this context) are…
And because it's in blender, that means that you could still use module_namespace::Error without conflict.
The full namespace path is blender::module_namespace::Error, though, so there's a…
I suppose another point is that "err" itself is also a word, meaning to make an error or mistake, so it kind of fits. It's not as common a word as "error", but I certainly have used it and see it…
In general, I agree. My rationale for going with Err in this case is:
- In theory, this should end up getting used a lot, so it will become familiar to people working in Blender's code base…
Yeah, that's a good point. For now I'll leave it in the PR (to get feedback on the docs at the same time as the Result type itself continues to iterate), but I'll leave this comment unresolved…