Re: [go-nuts] API fixes for sync.Mutex and friends?

[Steven Hartland]

The various meta linters pick this up.

I would highly recommend using: 
https://github.com/alecthomas/gometalinter to improve the quality of 
code, for this and other issues not picked up by the standard tool chain.


    Regards
    Steve

On 03/04/2018 00:37, Andrew Pennebaker wrote:
Some Go types like sync.Mutex have a subtle API issue, where the 
objects really shouldn't be copied or passed around into different 
function calls, e.g. to a goroutine worker. However, this is not 
enforced by the current API, but merely mentioned in the 
documentation, which is easily ignored.


Is there a way to better protect these types, so that users can't 
accidentally copy and corrupt them? Maybe a linter or the Go compiler 
could check for these types being passed in non-pointer form to 
function calls. I wonder if this problem still appears in Rust, or if 
the borrow checker could model this API distinction more safely and 
automatically?

--
You received this message because you are subscribed to the Google 
Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to golang-nuts+unsubscr...@googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] API fixes for sync.Mutex and friends?

[andrey mirtchovski]

this is https://github.com/golang/go/issues/8005, i believe.

On Mon, Apr 2, 2018 at 5:37 PM, Andrew Pennebaker
 wrote:
> Some Go types like sync.Mutex have a subtle API issue, where the objects
> really shouldn't be copied or passed around into different function calls,
> e.g. to a goroutine worker. However, this is not enforced by the current
> API, but merely mentioned in the documentation, which is easily ignored.
>
> Is there a way to better protect these types, so that users can't
> accidentally copy and corrupt them? Maybe a linter or the Go compiler could
> check for these types being passed in non-pointer form to function calls. I
> wonder if this problem still appears in Rust, or if the borrow checker could
> model this API distinction more safely and automatically?
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] API fixes for sync.Mutex and friends?

[Andrew Pennebaker]

Some Go types like sync.Mutex have a subtle API issue, where the objects 
really shouldn't be copied or passed around into different function calls, 
e.g. to a goroutine worker. However, this is not enforced by the current 
API, but merely mentioned in the documentation, which is easily ignored.

Is there a way to better protect these types, so that users can't 
accidentally copy and corrupt them? Maybe a linter or the Go compiler could 
check for these types being passed in non-pointer form to function calls. I 
wonder if this problem still appears in Rust, or if the borrow checker 
could model this API distinction more safely and automatically?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.