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")
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.
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
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
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
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
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
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