Erik Erlandson
Erik Erlandson
@soronpo so you'd prefer an idiom like `conv : OpConv[T => Rational[_, _], Rational[N, D]]` instead of `OpGen.Aux[ToRational[T], Rational[N, D]]` ?
> That is, unless the user requires an explicit ToRational I see that as a library policy convention question - do you want a `ToRational`, or do you want users...
The idiom `OpConv[T => Float, FloatVal]` isn't really any more wordy than `OpFloat.Aux[ToFloat[T], FloatVal]`. I can imagine updating the entire library conventions around type-casting to `=>`
> They don't do the same thing (conversion vs. just an auxiliary). I do not understand this distinction
> One is .toInt while the other is .asInstanceOf[Int], but within the typelevel world > The only reason you require OpCast derivatives such as OpAuxInt is when using upper-bounds. OK...
Link to trino slack thread: https://trinodb.slack.com/archives/CGB0QHWSW/p1661871177930719
Checking in to see if there is a fix for this.
Studying code, the sanest approach I can think of that might work is to modify the biz-logic in the `TrinoDialect` methods to attempt a split of `schema` on `.` and...
Getting `refineMV` working in scala3 would also make the integration with `coulomb` nicer, but primarily I want it for unit testing, and I'm sure I can work around it. https://github.com/erikerlandson/coulomb/pull/392