Watch as this gets rejected for nonsensical reasons just like the issue about adding uint128, which also has been open for an extremely long time and they keep moving the goalposts as to reasons why it can't be done...
It’s accepted.
Go: Support for Generic Methods
191–200 of 288 posts
Re: Go: Support for Generic Methods
#192Watch as this gets rejected for nonsensical reasons just like the issue about adding uint128, which also has been open for an extremely long time and they keep moving the goalposts as to reasons why it can't be done...
It’s accepted.
Now there's a surprise. I've generally been very disillusioned with Go after they absolutely stonewalled everybody on uint128 (and continue to do so) for absolutely no reason (and ignoring that it would make many things in the language easier to express).
Re: Go: Support for Generic Methods
#193Earlier quoted context omitted.
Is anyone actually mad about this, or do people just bring it up to stir the pot? Who cares what the FAQ says? They've worked out a way to add it easily in a backwards compatible way that can solve some problems. They had not identified this solution at the time they wrote the FAQ, and Go has been perfectly usable without this feature for 16 years.
I'm not mad, I'm a proponent of stronger type systems. I'm just correcting the record about > They didn't say they never wanted to do generics, but that they did want to take their time and do them right.
What’s the correction? The two claims are not in conflict. Saying “we don’t expect to ever add X” is not equivalent to “we never wanted to add X.” It simply means that they didn’t think it would happen, which can coexist with an underlying willingness to consider it if a suitable approach appeared.
Re: Go: Support for Generic Methods
#194Re: Go: Support for Generic Methods
#195slowly implementing all the things they said we didn't need
What did they say about proper enums.
You already have iota. Type safety is not needed by design:
> Go intentionally has a weak type system... Go in general encourages programming by writing code rather than programming by writing types...
https://github.com/golang/go/issues/29649#issuecomment-45482...
Re: Go: Support for Generic Methods
#196Re: Go: Support for Generic Methods
#197Go becoming a proper 21st century language, is like pulling teeth. It is Apple's school of design, think different, ah, actually, there are reasons why the fence is in the middle of nowhere. Then the design ends up half way there versus being done properly from the beginning.
“Done properly from the beginning” means explaining why a particular feature is either included or not. In this sense, Go is done properly from the beginning. It would be wrong to add every popular feature uncritically.
Re: Go: Support for Generic Methods
#198Earlier quoted context omitted.
What did they say about proper enums.
You already have iota. Type safety is not needed by design: > Go intentionally has a weak type system... Go in general encourages programming by writing code rather than programming by writing types... https://github.com/golang/go/issues/29649#issuecomment-45482...
Theres a whole universe between proper enums and go becoming Ada. Same with null safety.
Re: Go: Support for Generic Methods
#199Go becoming a proper 21st century language, is like pulling teeth. It is Apple's school of design, think different, ah, actually, there are reasons why the fence is in the middle of nowhere. Then the design ends up half way there versus being done properly from the beginning.
“Done properly from the beginning” means explaining why a particular feature is either included or not. In this sense, Go is done properly from the beginning. It would be wrong to add every popular feature uncritically.
"They are likely the two most difficult parts of any design for parametric polymorphism. In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU and C++ concepts earlier."
Yeah very critically.
Re: Go: Support for Generic Methods
#200Since they can't implement interfaces, Generic methods are just syntax sugar for generic functions. I'm surprised they actually accepted this proposal for sugar.