Go 2, here we come • Hacker News Board

Re: Go 2, here we come

#531

Post by Vendan » Mon, Dec 03, 2018, 5:46 AM UTC

scott_s wrote: post #519

Vendan wrote: post #518

Earlier quoted context omitted.

no, I get that, but int is not for pointer integer conversions. That is very specifically a separate type: uintptr an unsigned integer large enough to store the uninterpreted bits of a pointer value https://golang.org/ref/spec#Numeric_types

Sure, but did I imply it was? I’m genuinely confused.

> language allows casting pointers to integers

The original thread was about converting int to be an arbitrary precision type: "so that 'int' can become a true integer". One would imagine that, to preserve the ability to do pointer non-pointer number, they would just leave uintptr alone, and so basically ignore your concerns, whereas int as the "native type" for slice indexes and the like is a more likely reason to prevent messing with "int" itself

Re: Go 2, here we come

#532

Post by scott_s » Tue, Dec 04, 2018, 3:46 PM UTC

Vendan wrote: post #531

scott_s wrote: post #519

Earlier quoted context omitted.

Sure, but did I imply it was? I’m genuinely confused.

> language allows casting pointers to integers The original thread was about converting int to be an arbitrary precision type: "so that 'int' can become a true integer". One would imagine that, to preserve the ability to do pointer non-pointer number, they would just leave uintptr alone, and so basically ignore your concerns, whereas int as the "native type" for slice indexes and the like is a more likely reason to p…

Okay, that's the source of the confusion. I was not replying to that sentiment, which is a nuanced discussion on what an int should be. I was replying to the_clarence's categorical dismissal of variable width integer types.

Re: Go 2, here we come

#533

Post by stcredzero » Fri, Dec 07, 2018, 5:07 PM UTC

dnautics wrote: post #459

stcredzero wrote: post #386

Earlier quoted context omitted.

The more nuanced and better side of that is that any language is better without badly designed and badly implemented generics.

Maybe the even more nuanced side is that a language that can't conjure a safe and well designed generic has a badly designed type system in the first place

That sounds axiomatic.

How would you define "badly designed?" I can imagine a context where the "well designed" type system is very plain.

Re: Go 2, here we come

#534

Post by stcredzero » Fri, Dec 07, 2018, 11:29 PM UTC

hhmc wrote: post #332

copperx wrote: post #96

Earlier quoted context omitted.

That's a good question because they ostensibly do it to get more users aboard, but in most cases, the result is the opposite (e.g., the Python 2/3 disaster).

C++11 introduced breaking changes ( https://stackoverflow.com/questions/6399615/what-breaking-ch... ) but is widely regarded as a boon to the language.

Yes, but in large part, those changes were quite obscure, in comparison to things like how to define classes.