[coder543]

I would just recommend constructing them as Amplitude values to begin with and avoid the need for a transmute. That Vec isn’t going to materialize out of thin air, and there’s no cost to using one of these zero size wrappers from the beginning.

But, yes, you probably could transmute it... if you really have to.

[nyanpasu64]

What if you're interfacing with an audio output library and synthesis library that works with &[f32] and not a dimensioned type?

[coder543]

These scenarios are so hypothetical that it’s pointless to give an answer. What if the library requires you to pass in values in a custom struct they defined? What if the library requires all sorts of arbitrary nonsense?

The reality is that the conversion cost to just `map` one Vec to another is extremely low on anything but maybe a microcontroller —- and even then, maybe not.

If you benchmark things and can’t find a safe way to do things, there are unsafe methods, but I am highly skeptical that they would be needed.

It’s also extremely possible to fork such a library, change a few lines to use the dimensionally correct type, and be done with the issue.

If all of your heavy lifting is being done by this external library anyways, and that library just uses raw floats... why bother with the ceremony of using a dimensionally safe float in your own code if the performance cost of mapping between types is too high?

The real benefit of dimensional safety is when you’re actually doing computations, not some external library you pulled in.

Rust allows for these zero cost wrapper types that will do exactly the correct computations as if they were done with hand written code... but you have to actually have computations that you want to do. The type system intentionally doesn’t want you to treat these typed floats as regular floats. That’s the point.

But there are ways to transmute certain types for no performance penalty, they’re just footguns you should avoid except as an option of last resort.

[nyanpasu64]

> These scenarios are so hypothetical that it’s pointless to give an answer.

Every audio library I've seen so far operates on (*i16/f32, size_t) or &[i16/f32]. An audio library which supports dimensioned values is hypothetical. And most dimensioning libraries don't have a unit of "sample" (in time) or "audio amplitude" or "channel", so the audio library won't even know what unit system to pick.

> It’s also extremely possible to fork such a library, change a few lines to use the dimensionally correct type, and be done with the issue.

And suddenly the audio library is tied to your specific unit system, and you still need transmutes or whatnot when talking to the OS sound library.

> If all of your heavy lifting is being done by this external library anyways, and that library just uses raw floats... why bother with the ceremony of using a dimensionally safe float in your own code if the performance cost of mapping between types is too high?

Most of the time I end up just using a named type alias, instead of a strong newtype.