Thinking about this over morning coffee it is more complex. It is not just
sequential consistency that affects it - placing the struct in a map or some
other reference container would also have to force a copy.
Less and less utility.
> On Mar 11, 2020, at 3:33 AM, Robert Engels wrote:
>
>
True. But in the current situation, if the object was large, you either do a
copy (bad) or use a pointer and synchronize (worse?) - or you have to be
sequential.
So, const could also carry with it sequential requirements (prohibited to be
captured by a Go routine), or alternatively, if capture
On Tue, Mar 10, 2020 at 10:08 PM robert engels wrote:
>
> I think what the OP was trying to say, is that with ‘const’ the compiler
> could safely use a pointer receiver rather than a copy, and also enforce that
> const are not modified, and only passed as const args (may require a heap
> alloca
I think what the OP was trying to say, is that with ‘const’ the compiler could
safely use a pointer receiver rather than a copy, and also enforce that const
are not modified, and only passed as const args (may require a heap allocation
though, so maybe only if struct is of a certain size based o
On Tue, Mar 10, 2020 at 9:49 PM 'aaa bbb' via golang-nuts
wrote:
>
> I test a code in go tour, and get a nil error at first:
>
>
> func say(s string, ch chan int) {
>
> for i := 0; i <= 5; i++ {
>
> time.Sleep(100 * time.Millisecond)
>
> fmt.Println(s)
>
> }
>
> ch <- 1
>
> }
>
>
> func main() {
>
I test a code in go tour, and get a nil error at first:
func say(s string, ch chan int) {
for i := 0; i <= 5; i++ {
time.Sleep(100 * time.Millisecond)
fmt.Println(s)
}
ch <- 1
}
func main() {
//var ch chan int
