Problems with "muddy" (ie not properly transparent) type aliases..

[benhutchison]

Apologies in advance, this is a only semi-digested problem report that troubles and intrigues me.

I have a basetype package which exports coulomb to my application, and also declares some common aliases:

package basetypes

import scala.annotation.targetName

export coulomb.{Quantity, DeltaQuantity, `*`, `/`, `^`, showUnit, Unitless}
export coulomb.syntax.{withUnit, withDeltaUnit}
export allalgebra.{*, given}
export coulomb.ops.algebra.all.given
export coulomb.policy.standard.given
export scala.language.implicitConversions
export coulomb.units.time.{*, given}
export coulomb.units.si.{Second as _, ctx_unit_Second as _, *, given}
export coulomb.units.si.prefixes.{*, given}

//experiment
export coulomb.units.javatime.{*, given}
export coulomb.units.javatime.conversions.all.{*, given}

import coulomb.conversion.*

private object allalgebra extends algebra.instances.AllInstances

//..snip..
type Seconds = Quantity[Long, Second]

extension [UT](time: Quantity[Long, UT])
  @targetName("longAsMillis")
  transparent inline def asMillis(using TruncatingUnitConversion[Long, UT, Milli * Second]) = time.tToUnit[Milli * Second]

But the use site for asMillis:

  def aggregatedIntervalsStream[F[_]](tradePointStream: Stream[F, TradePoint], n: Int, offset: Seconds = 0.seconds): Stream[F, (TradePoint, Int)] =
    require(n > 0)
    val oms = offset.asMillis
    //..

Wont compile. The whole error msg is:

[error] 40 |      val oms = offset.asMillis
[error]    |                ^^^^^^
[error]    |Found:    (time$proxy1 : (offset : basetypes.Seconds) &
[error]    |  coulomb.Quantity[Long, $proxy4.Second]
[error]    |)
[error]    |Required: coulomb.quantity$package.Quantity[Long, coulomb.units.si.Second²]
[error]    |
[error]    |where:    Second  is a type in package object Basetypes$package which is an alias of coulomb.units.time.Second
[error]    |          Second² is a type in object si with bounds
[error]    |

What I find troubling is:

1. What is this type (offset : basetypes.Seconds) & coulomb.Quantity[Long, $proxy4.Second]? Since Seconds is defined as Seconds = Quantity[Long, Second], this type looks like an intersection with itself!? Why cant the compiler unify it?/

2. The types Second and Second² are the same, one is just an alias for the other. why is the compiler talking as if they're different?

It seems like the compiler can't see through some type aliases, either the Second alias in basetypes, or else the export aliases created by export clauses..

[erikerlandson]

I frequently find it hard to distinguish between real problems and red herrings, but I do know that coulomb tends to work most smoothly with fractional value types (double, rational, etc), because integral types require most conversions to be explicit.

I see you working a lot with Long and I'm wondering if Double would be sufficient, since it also has 53 integer bits of precision.

Or, you could try implementing your own scala.Conversion implicits for Long, to see how much that smooths things out.

I still suspect that Scala has a few rough edges around export and type aliases but it would remove some sources of error and maybe make it easier to isolate "real" things.

[benhutchison]

I'm working with timestamps and discrete events measured as millis or seconds since 1970, and need to convert back to raw Longs at external API boundaries.

[benhutchison]

My gut feel is that there's definitely problem(s) where Scala 3 can fail to recognise that aliases of a type are the same thing.

Things I want to investigate are:

• Is it specifically related to export aliases or can it happen for regular type X = Y too?
• If multiple aliases stack (eg type X = Y; type Y = Z), including export aliases, can that cause issues? ie does it sometimes fail to de-alias transitively?

One thing I was going to try was to strip out absolutely every export, and see if the problem resolves. My own, but also coulomb's time module, which aliases Second. I was going to do this by creating a custom patched version of time in my own codebase that just uses import.