Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go 1.27

go.dev

Post reply on HN
Print view View original

171–180 of 277 posts

Re: Go 1.27

#171

Post by 0x696C6961 »

pjmlp wrote: post #158

Struct literal changes while welcomed, have the issue of being a possible source of bugs, if there are overlapping fields, type Habitat struct { Burrow string } type Gopher struct { Name string Burrow string Habitat } It will not initialise what one expects, here it is a contrived example, however it may not be easy to spot in more complex source code. https://go.dev/play/p/dsY6tK5S8Ie Better generics and improved SI…

Mhm, probably worth a golang-ci check for duplicate field names which are accessed by methods on the embedded type.

Re: Go 1.27

#172

Post by pjmlp »

j3nz wrote: post #168
pjmlp wrote: post #158

Struct literal changes while welcomed, have the issue of being a possible source of bugs, if there are overlapping fields, type Habitat struct { Burrow string } type Gopher struct { Name string Burrow string Habitat } It will not initialise what one expects, here it is a contrived example, however it may not be easy to spot in more complex source code. https://go.dev/play/p/dsY6tK5S8Ie Better generics and improved SI…

I'd say it is as expected https://go.dev/play/p/sy6SMrOiw4y

I would at least expect a go vet warning in such cases.

Re: Go 1.27

#173

Post by pjmlp »

0x696C6961 wrote: post #171
pjmlp wrote: post #158

Struct literal changes while welcomed, have the issue of being a possible source of bugs, if there are overlapping fields, type Habitat struct { Burrow string } type Gopher struct { Name string Burrow string Habitat } It will not initialise what one expects, here it is a contrived example, however it may not be easy to spot in more complex source code. https://go.dev/play/p/dsY6tK5S8Ie Better generics and improved SI…

Mhm, probably worth a golang-ci check for duplicate field names which are accessed by methods on the embedded type.

Better would be a got vet check.

I understand the need not to break existing code that might have such fields.

Re: Go 1.27

#174

Post by 0x696C6961 »

pjmlp wrote: post #173
0x696C6961 wrote: post #171

Earlier quoted context omitted.

Mhm, probably worth a golang-ci check for duplicate field names which are accessed by methods on the embedded type.

Better would be a got vet check. I understand the need not to break existing code that might have such fields.

I think that's a no-go because vet checks have no-false-positive policy. Ie, when go vet flags something, its a bug.

Re: Go 1.27

#175

Post by amelius »

Retr0id wrote: post #82
amelius wrote: post #74

Earlier quoted context omitted.

Ok, but when is it coming to our web browsers and email clients?

I don't know about mail clients, but it's in most web browsers already.

Then I'm wondering why they don't simply use the same crypto libraries as the web browsers.

Re: Go 1.27

#176

Post by ksec »

win311fwg wrote: post #138
AdieuToLogic wrote: post #135

Earlier quoted context omitted.

> Generics were always planned, of course ... This is provably incorrect. The position held for many years by the language authors was[0]: Generics may well be added at some point. We don't feel an urgency for them, although we understand some programmers do. Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to t…

Considering that Ian was already working on them before 1.0, and never stopped until a solution was found, we know for certain they were planned by at least one person on the Go team. If you are struggling to say that Go people are not a single monolith then sure. Nobody has ever thought people are a single monolith. However, the original announcement makes the intent of the project clear: "Not yet", not "never". The…

Do we know if Go team is working in 2.0 release?

Re: Go 1.27

#177

Post by LandR »

JodieBenitez wrote: post #141
pregnenolone wrote: post #40

Wasn't Go supposed to be "simple"? I remember how Go advocates used to boast about not having generics and now it almost seems like Go is trying to become some sort of C# or Java Frankenstein. I'm not even trying to badmouth Golang - just legitimately confused.

I'm pretty sure there is a silent majority of Go users who don't want/need/know about generics.

And they can simply not use them ?

Re: Go 1.27

#178

Post by dgunay »

knocte wrote: post #142
Xeoncross wrote: post #17

> First, generic methods are now supported > Generic functions can now be used without explicit type arguments Great! This was an ergonomic code issue I hit when trying to create a universal handler/controller generic that could hydrate/populate function arguments (from a request body) without having an actual copy of the arguments: https://github.com/xeoncross/mid/blob/main/handler.go#L12

Can proper Result/Option types be created for Go now?

You can do pipelined option/result manipulation now, but without sum types/pattern matching it's not going to be quite as useful as Rust's.

Re: Go 1.27

#179

Post by pjmlp »

0x696C6961 wrote: post #174
pjmlp wrote: post #173

Earlier quoted context omitted.

Better would be a got vet check. I understand the need not to break existing code that might have such fields.

I think that's a no-go because vet checks have no-false-positive policy. Ie, when go vet flags something, its a bug.

I would say that initialising the wrong field because a dev is unaware of a clash between Gopher.Burrow and Gopher.Habitat.Burrow (naturally in more complex code), when upgrading to 1.27 and taking advantage of the feature without realising it, is a bug.

Re: Go 1.27

#180

Post by amiga386 »

pjmlp wrote: post #158

Struct literal changes while welcomed, have the issue of being a possible source of bugs, if there are overlapping fields, type Habitat struct { Burrow string } type Gopher struct { Name string Burrow string Habitat } It will not initialise what one expects, here it is a contrived example, however it may not be easy to spot in more complex source code. https://go.dev/play/p/dsY6tK5S8Ie Better generics and improved SI…

Go has had this behaviour for promoting fields (provided they don't clash) for some time, this is just extending the language feature to initialisers.

Your contrived example doesn't initialise the embedded struct that also contains a "Burrow" field. If it did that at all, even without naming the Burrow field... you would not be allowed to initialise the struct, because of the ambiguity.

https://go.dev/ref/spec#Composite_literals

> A key must not denote a promoted field inside an embedded struct if that struct is also specified by another key.

> Given the declarations

    type Object  struct { name, color string }
    type Point3D struct { Object; x, y, z float64 }
    type Line    struct { Object; p, q Point3D }
> .... field selectors may not denote overlapping fields:

    obj   := Object{"edge", "black"}
    line3 := Line{Object: obj, name: "diagonal"} // invalid: name denotes a field inside Object
Post reply on HN