Re: Workaround for value class type erasure?

Could we get native UInt and ULong in Dotty please? That has really annoyed 
(not only) me about Java and Scala.

Why can't the compiler handle the necessary boilerplate required for each 
VM?

For now the compiler could just stub in your library.

On Thursday, May 9, 2013 at 10:16:34 PM UTC+8, Nate Nystrom wrote:
>
> You can also use a dummy implicit: 
>
> def foo(x: Int)(implicit d: DummyImplicit): UInt = ??? 
> def foo(x: UInt): UInt = ??? 
>
> I use this in my own UInt implementation: 
>
>
> https://github.com/nystrom/scala-unsigned/blob/master/src/main/scala/passera/unsigned/ULong.scala 
> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fnystrom%2Fscala-unsigned%2Fblob%2Fmaster%2Fsrc%2Fmain%2Fscala%2Fpassera%2Funsigned%2FULong.scala&sa=D&sntz=1&usg=AFQjCNHvzoeW4DD2htQx88PJwrLZZRb-Rg> 
>
> Nate 
>
>
>
> On Thu, May 9, 2013 at 3:32 PM, Sébastien Doeraene 
> <[email protected] <javascript:>> wrote: 
> > Hello, 
> > 
> > I would explore other designs first, but if you really need to have the 
> > interface you describe, you can go for default parameters: 
> > 
> > def foo(x: Int): UInt = ??? 
> > def foo(x: UInt, dummy: Int = 0): UInt = ??? 
> > 
> > Cheers, 
> > Sébastien 
> > 
> > 
> > On Thu, May 9, 2013 at 3:17 PM, Erik Osheim <[email protected] 
> <javascript:>> 
> > wrote: 
> >> 
> >> On Thu, May 09, 2013 at 02:52:34PM +0200, Mark Hammons wrote: 
> >> > Right now I'm having trouble with overloading. I have function a with 
> >> > signatures Int => UInt and UInt => UInt. It fails to compile because 
> of 
> >> > double definition. Is there a way to get past this issue? 
> >> 
> >> I don't think you can do this without introducing a third type: 
> >> 
> >> case class UIntBoxed(u: UInt) { ... } 
> >> 
> >> class UInt(val n: Int) extends AnyVal { 
> >>   implicit def box = UIntBoxed(this) 
> >> } 
> >> 
> >> object Qux { 
> >>   def apply(n: Int) = ... 
> >>   def apply(n: UIntBoxed) = ... 
> >> } 
> >> 
> >> Of course, this will negate the runtime benefits of using a value 
> >> class in the first place. In my opinion, overloading based solely on 
> >> value class types is antithetical to their purpose--it would be better 
> >> to use different method names or have the user provide some other 
> >> indicator of desired behavior. 
> >> 
> >> -- Erik 
> >> 
> >> P.S. If you're defining UInt you may be interested to compare your 
> >> implementation with Spire's: 
> >> 
> >> 
> >> 
> https://github.com/non/spire/blob/2.10.0/core/src/main/scala/spire/math/UInt.scala 
> >> 
> >> -- 
> >> You received this message because you are subscribed to the Google 
> Groups 
> >> "scala-language" group. 
> >> To unsubscribe from this group and stop receiving emails from it, send 
> an 
> >> email to [email protected] <javascript:>. 
> >> For more options, visit https://groups.google.com/groups/opt_out. 
> >> 
> >> 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "scala-language" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to [email protected] <javascript:>. 
> > For more options, visit https://groups.google.com/groups/opt_out. 
> > 
> > 
>

-- 
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.