[go-nuts] What is the correct way to access/modify slice elements concurrently

2019-11-07 Thread Kasun Vithanage
Assume we have a type like follows type Foo struct { Alive bool } type Bar struct { Foos []*Foo } In two goroutines we are supposed to read and write the Alive variable. For example func (b *Bar) CheckFoosAlive() { for i := 0; i < len(b.Foos); i++ { if b.Foos[i].Alive { fmt.Println("Alive")

[go-nuts] GORM model change log

2019-11-07 Thread Antonio
Hi All, I'm coming from rails where model versioning was easy to add to any app. I found it hard to find something like paper_trail or acts_as_versioned equivalents in golang for gorm, I did however find gorm-loggable which seems like it covers what I need.

Re: [go-nuts] strict type assignability to prevent arbitrary values

2019-11-07 Thread Mohamed Yousif
Hi Speter, Can you elaborate more on this point please? > there is no memory or runtime overhead due to encapsulating the string within a struct. On Thu, 7 Nov 2019 at 3:15 PM, speter wrote: > Hi bsr, > > I'd suggest to use a struct type with a single string field. It will > prevent

[go-nuts] An infrastructure-as-code tool for Go

2019-11-07 Thread burak serdar
Hello, I'd like to announce a side-project I've been working on after some frustration with existing infrastructure-as-code tools. It is written in Go, and allows you to write infrastructure as code using Go. It can be extended to use any language supporting gRPC. This is the open-source version

Re: [go-nuts] strict type assignability to prevent arbitrary values

2019-11-07 Thread bsr
Thanks Jan & Peter. I would use one of the approaches. On Thursday, November 7, 2019 at 8:15:20 AM UTC-5, speter wrote: > > Hi bsr, > > I'd suggest to use a struct type with a single string field. It will > prevent conversion from untyped string constant "by mistake". > Moreover, if you make the

Re: [go-nuts] strict type assignability to prevent arbitrary values

2019-11-07 Thread speter
Hi bsr, I'd suggest to use a struct type with a single string field. It will prevent conversion from untyped string constant "by mistake". Moreover, if you make the string field unexported, you can limit new instance creation to the declaring package, allowing to enforce predefined values. Unlike

Re: [go-nuts] strict type assignability to prevent arbitrary values

2019-11-07 Thread Jan Mercl
On Thu, Nov 7, 2019 at 11:58 AM bsr wrote: > Is there a way I can prevent this behavior. Yes, if the rules for untyped literals are not wanted, make the literal typed: https://play.golang.org/p/-f75y0Gb1Is -- You received this message because you are subscribed to the Google Groups

[go-nuts] strict type assignability to prevent arbitrary values

2019-11-07 Thread bsr
Hello, I am a long time user of go, but I always had the impression that below code would not work as string and Status are different type. I thought I need to explicitly convert as ```exec(Status("abc"))``` it to work. I think, this part of the spec may be the reason