Re: Confusion on implicit integer conversion.
> I had never actually considered C to be a 'weakly typed' language. There seem > to be various opinions on that particular subject both for and against. There is far less debate about whether C is weakly typed than there is about what the term means. I used the language for 40 years and served on the C language standards committee and I've never seen any sign of a debate on this issue -- no one has ever called C strongly typed. I could point to printf and casting of pointers to other pointer types (or to and from void* without even needing a cast) or even to integers (when I started using C you didn't even need a cast) as glaring examples.
Re: Confusion on implicit integer conversion.
Yeah, file an issue. They work like in C++ or other languages, the first usage binds the type to the type variable other usages check for consistency with the bound type. As mratsim already explained: > The signature of the proc is proc +[T: SomeInteger](x, y: T): T T is bound to > uint32 in the first case, and we can convert uint16 to uint32 losslessly. In > the second case, T is bound to uint16 and we can't convert uint32 to uint16 > losslessly. .
Re: Confusion on implicit integer conversion.
@Araq Should I raise an issue? Also would you be able to elaborate on 'how generic parameters work'?
Re: Confusion on implicit integer conversion.
IMO it's just a system.nim bug caused by misunderstandings about how generic parameters work.
Re: Confusion on implicit integer conversion.
@mashingan >tldr; if the size of integer is important, always opt to explicit conversion That seems to be very good advice. I was considering defining my own operators, but it seems like the first option is the most sensible. @mratsim I had never actually considered C to be a 'weakly typed' language. There seem to be various opinions on that particular subject both for and against. I can see what you are saying though, C is definitely **more** weakly typed than Nim, and I had not considered the differences in philosophy. Thanks again everyone for your advice.
Re: Confusion on implicit integer conversion.
@mashingan >tldr; if the size of integer is important, always opt to explicit conversion That seems to be very good advice. I was considering defining my own operators, but it seems like the first option is the most sensible. @mratsim I had never actually considered C to be a 'weakly typed' language. There seem to be various opinions on that particular subject both for and against. I can see what you are saying though, C is definitely **more** weakly typed than Nim, and I had not considered the differences in philosophy. Thanks again everyone for your advice.
Re: Confusion on implicit integer conversion.
I'd also add to @mashingan answer than Nim is a strongly typed language. Lossless conversion are made explicit for safety reason, we don't want you to lose information or data by something done under-the-hood and very time-consuming to debug. Other strongly typed languages might just plain prevent you from promoting uint16 to uint32 implicitly.
Re: Confusion on implicit integer conversion.
_tldr; if the size of integer is important, always opt to explicit conversion_ * * * you can define your own `+` operator for your case proc `+`(x: uint16, y: uint32): uint32 = x.uint32 + y Run But then the definition then become tedious if you have to define another with proc `+`(x: uint32, y: uint64): uint64 = x.uint64 + y Run again and again. So the `+` is defined as generic. Since generic doesn't know which type should it bind to, so it's logical choice to bind to first argument.
Re: Confusion on implicit integer conversion.
@cdome, thanks for the suggestion, but I am working with serial protocols involving integers of different lengths, so lenientops is not much help. It works by converting between int and float. @mratsim, thank you for the explanation. As an experienced user (I've seen your sig many times) can you shed some light on why the language imposes this restriction? Nim is an extremely complicated language making it quite difficult to learn. It seems to be a very poor design choice to overly complicate even this most basic of operations by imposing operand order. Is there an underlying advantage somewhere that I am missing? What is wrong with promoting either operand (the way every other language ever invented does)? This is not intended to be a rant, I'm just trying to understand the motivation. Thanks again for your advice.
Re: Confusion on implicit integer conversion.
there is module in standard library: lenientops. it should help
Re: Confusion on implicit integer conversion.
The signature of the proc is proc `+`[T: SomeInteger](x, y: T): T Run T is bound to uint32 in the first case, and we can convert uint16 to uint32 losslessly. In the second case, T is bound to uint16 and we can't convert uint32 to uint16 losslessly.
Confusion on implicit integer conversion.
Hi, I have a simple question. The Nim manual says that integer operations will promote the smaller of the two to the larger, but that behavior only seems to hold true with specific operand order, eg: `` var arg1:uint32 var arg2:uint16 arg1 = 10 arg2 =12 echo(arg1 + arg2) #works echo(arg2 + arg1) #fails `` Why does the order of addition matter?
