`toRadians` and `toDegrees`. Both are present in `java.lang.Math` but for MP it's a problem

# stdlib

[elect]

toRadians and toDegrees. Both are present in java.lang.Math but for MP it's a problem

[Klitos Kyriacou]

I was about to comment that toRadians and toDegrees would work very nicely with value classes, but then realised that these require @JvmInline so are not usable with multiplatform 🤦‍♂️

[ephemient]

value classes work on all platforms, it's only JVM that requires the annotation to disambiguate from future Valhalla value types

[Klitos Kyriacou]

Ah, that's good! I only use Kotlin on the JVM, so wasn't aware of that!

[ilya.gorbunov]

I prototyped once such value classes and found the result not satisfying.
If we provide them only to do the conversions, it's not much better than providing just these functions, and if we specialize trigonometric functions to accept these types, it will require a lot of overloads, and in some cases - overloading by return type which is not possible. For example, what would be the return type of asin(...) (arc sine) function, if there are several types for angular units?

[Klitos Kyriacou]

That makes sense. Perhaps we can keep treating radians as the "natural" unit of angle, and require special treatment for degrees:

val rightAngle = 90.deg                       // property deg is defined on Double (or Number)
val y: Double = sin(rightAngle.toRadians())   // sin is only defined for radians
val theta: Radians = asin(y)                  // asin(Double) returns Radians
val theta2 = theta.toDegrees()                // toDegrees() is defined on Radians

[ephemient]

a vaguely related thought… do we really need to represent angles outside of `-*π..<π`/`-*180°..<180°`? (or maybe some small multiple of that)
if not, given the same storage size, a fixed-point representation covering that range could have more useful precision than the subset of floating point numbers within that range

[Klitos Kyriacou]

That's an interesting thought, but there are real-world use cases in engineering, e.g. "this bolt should be turned 720° clockwise", or you might want to convert rpm to radians per second. Still, the increased precision you talk about sounds appealing.

[Michael de Kaste]

they could always be 2 different classes. One being angle, the other rotation

[Michael de Kaste]

and then define an operator fun Angle.plus(rotation: Rotation): Angle etc.

[Klitos Kyriacou]

I like that! It reminds me of Instant and Duration as being analogous. Also, we can define the properties Double.deg and Double.rad so they both return Angle , and Angle.toRadians(): Double (trivially returns the value) and Angle.toDegrees(): Double (converts value held in radians to degrees).

[elect]

overloading by return type which is not possible

cant @JvmName helps with that?

[ephemient]

no. the JVM doesn't care whether they have the same name or not, it's a language limitation

[elect]

I wish Kotlin could transparently mangle the names underneath for the JVM but offer the same names (taking into account different return type, inline classes as well) to the developer

[ephemient]

it doesn't matter if it's mangled or not, the JVM does not reject multiple methods with the same name and signature differing in return type only

[ephemient]

it's a language issue: Kotlin can't handle that (it'll definitely have interactions with type resolution). also even adding that, it'll be completely unusable from Java

[elect]

Except that there are already corner features unusable from Java, with JvmNames the dev could specify the name to be used underneath (and visible from Java)

[ephemient]

sure, but that's unrelated to the fact that Kotlin can't handle overloads by return type only, on JVM or any platform