If, for example, I were wanting to create a crazy new int type that stored its value as product of primes, and I was not concerned with performance, I could create my own pure nim type in a library.
type
intAP = object
setOfPrimes: array[0..50, int]
... and, using operator overloading, it would mostly work just like any other int. I could add, subtract, etc. and it would all behave just like any other int.
I can even mix the types. I could even add a int64 and a intAP together and return either a new int64 or intAP (depending on how I wrote it.)
But the one thing I can't do is plain assignment.
# works:
var a: int = 5
var b: int64 = 5
var c: int16 = 5
var d: float = 5
# doesn't work:
var e: intAP = 5
# workaround:
var e: intAP = createIntAP(5)
This isn't a deal breaker. But it would really be nice if the operator overload proc allowed for different target types.
Akin to:
proc `=`(n: var intAP, target:intAP) =
n.setOfPrimes = target.setOfPrimes
proc `=`(n: var intAP, target:int) =
# blah blah blah mathy stuff
Various places in the forum it has been hinted that this might one day be possible. So, two questions: Does this cause any fundamental problems? Is it on the roadmap?
Just curious.
Perhaps like this
type IntAp = object
setInts: array[0 .. 2, int]
converter toIntAp(n: int): IntAp =
let ints = [n, 0, 0]
IntAp(setInts: ints)
let n: IntAp = 5
No need apologize! Holy cow ... how did I not know about converter? I've been coding Nim for over a year now and I just now learned of it.
I will have to re-read the manuals again. I wonder if there are any other hidden nuggets I've missed.
By the way, to restrict conversion to literals you can use the {lit} constraint
converter toIntAp(n: int{lit}): IntAp
Otherwise some subtle bugs might be introduced where you or your user do not want because an int was converted silently to IntAp.