News for hackers. Stuff that matters.
Re:Visual Studio Code for Go by Someone1234 on Thursday March 03, 2016 @01:15PM (#11218699)
> It's inexplicable to me why a language wouldn't allow these loss-less operations to be implicit.

Because in some sense implicit behaviour is bad behaviour. It makes it unclear what the code does.

Re:Visual Studio Code for Go by 0xffff2 on Thursday March 03, 2016 @01:24PM (#11218763)
I guess that's exactly what I don't understand. If I add a 32-bit integer and a 64-bit integer, what other possible result could I be expecting besides a 64 bit integer?
Re:Visual Studio Code for Go by dragonwriter on Thursday March 03, 2016 @01:45PM (#11218931)
> If I add a 32-bit integer and a 64-bit integer, what other possible result could I be expecting besides a 64 bit integer?

A 128-bit integer (if you are adding a 32-bit integer and a 64-bit integer, the smallest power-of-2-bits representation guaranteed not to have an overflow is 128-bits, so its the safest result. Though, I'd agree, not the most likely thing most programmers would intend.)

Re:Visual Studio Code for Go by 0xffff2 on Thursday March 03, 2016 @02:08PM (#11219159)
Good point. As painfully explicit as Rust is at times, I'm actually slightly surprised they didn't go that route. (At least for integer sizes less than 32 bits.)
Re:Visual Studio Code for Go by Someone1234 on Thursday March 03, 2016 @01:27PM (#11218775)
An exception, a 32 bit integer, underflows, or overflows.
Re:Visual Studio Code for Go by Locke1689 on Thursday March 03, 2016 @02:24PM (#11219290)
That's a problem with addition, period, not type promotion. Adding a 64-bit and 32-bit integer and promoting the 32-bit integer to 64-bit doesn't produce any problems that you won't have adding two 32-bit integers together or two 64-bit integers.