Seems like this could apply to the SimpleMixer as well? At least they could use the same approach.

This ::type idea seems pretty strange, but I'll just accept it as some C++ template goodness : )

I was curious so I tried the following, but got a "lambdas not allowed in this context", which makes sense I guess

using DefaultMixer<int> = SimpleMixerWithAccumulationType<int, double, [](const double &value) {
  return static_cast<int>(value);
}>;

At first I thought this was inconsistent with the implicit conversion we use elsewhere (== 0.0f). Now I'm not sure though.

Another way of framing this is that the read attribute could become capable of owning its array, right? Seems a bit overkill at first to use a different class for this.
Might array_is_temporary_ and array_buffer_ be enough to implement this?
Maybe I'm missing something?

Since there will be many of these functions-- thinking a bit on how to make them a bit shorter:

• I don't think the component will be accessed here, maybe just use mesh as an argument. Unless you had a reason to do it this way.
• Do the convert_to_static_type step outside of this function, in the caller.

Then we wouldn't need the separate impl function here. Maybe some of those generalizations won't apply to the other conversions though, not sure.

In SimpleMixer store the weights separately, because the buffer is already allocated by the calling code.

This ::type thing is fairly normal in C++, see https://en.cppreference.com/w/cpp/types/remove_cv for example.

You're idea isn't too bad, but yeah, it just doesn't work with the current C++ standard.

I think mixing 99 false and 1 true should result in false. This is consistent with the mix3 function above.

Hm, this could be part of ArrayReadAttribute, but I'm not sure if it should. It would just make the memory management more manual.. Will think about it.

Passing in the mesh instead of the component seems fine.

The main motivation I'm doing the convert_to_static_type here was to keep it's scope small (the larger it's scope, the more code is generated for every type). It does not make much of a difference here though. I think this is something we can refactor when we add more domain conversions. Then we'll have a better idea of what abstraction works best.

Ah right, of course.

Ah, that's what it is, it's different because it's a mix, not just one conversion

Okay, thanks for the explanation. Then for now just changing the argument to Mesh is probably best.

I agree, will do that tomorrow.