16:14 <achin> i shared numbat.dev with some coworkers, and the very first question they asked was "can it convert celsius to fahrenheit" :)

16:15 <triallax> what'd they say when you answered yes?

16:15 <triallax> or wait, i guess there's no direct conversion

16:16 <triallax> from_celsius(100) -> fahrenheit

16:16 <triallax> this works but is kinda fiddly i guess

16:34 <achin> i actually didn't know howto answer, because in my local version, i have a custom celsius_to_fahrenheit function, and i didn't know how to do the conversion without it :)

20:24 <sharkdp> achin: Thank you for sharing.. and for the feedback. It is indeed embarrasing for such a complicated piece of software that we don't have a nice way to convert degF to degC. But we have a ticket for this https://github.com/sharkdp/numbat/issues/184, and I still believe we should find a way to support an input like "30°C to °F".

20:26 <sharkdp> The solution we have right now (from_celsius(30) -> fahrenheit) and everything else we come up with as hacks to add this to the language have the same problem. Those solutions are not "discoverable" by the user. We need to support things that users will type first (e.g. 30 celsius -> fahrenheit)

20:27 <triallax> do you have anything in mind on how to implement this without fundamental changes to numbat?

21:11 <sharkdp> I'm not sure fundamental changes are needed. But we need a new kind of unit and quantity (with additive offsets). And we need to think about whether or not we want/need to lift that information to the type system as well. We probably want to prevent things like "3°C + 4°C" at compile time.

21:12 <sharkdp> On the other hand, we would probably want to have an expression like "3°C" to be of type "Temperature" such that we can use it everywhere that a temperature is expected.

21:13 <sharkdp> Or maybe "3°C" is of type AdditiveOffset<Temperature>, where quanties of type AdditiveOffset<X> can decay to X implicitly.