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 on platform/compiler 
opts).

I think he has a point.

When you see a ‘pointer receiver’ a developer probably assumes the code needs 
to modify the structs - thus you must pass a pointer. But if you are only 
declaring a pointer to avoid an expensive large structure copy, you are giving 
misleading information - and possibly causing bugs due to incorrect later code 
modifications.


> On Mar 10, 2020, at 11:56 PM, Ian Lance Taylor <[email protected]> wrote:
> 
> On Tue, Mar 10, 2020 at 9:49 PM 'aaa bbb' via golang-nuts
> <[email protected] <mailto:[email protected]>> 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() {
>> 
>> 
>> 
>> //var ch chan int
>> 
>> var ch chan int = make(chan int, 1)
>> 
>> 
>> 
>> go say("world", ch)
>> 
>> fmt.Println("Hello")
>> 
>> <-ch
>> 
>> }
>> 
>> null reference error almost exists in every programming language.
>> so why not make directive that indicates a parameter is not allowed nil? like
>> 
>> func say(s string, ch chan int not nil) {...}
>> 
>> Or other more powerful validation mechanism.
> 
> These kinds of issues have been discussed before.  See, for example,
> https://golang.org/issue/30177 <https://golang.org/issue/30177>.
> 
> 
>> also, at the value receiver and pointer receiver section, sometimes we 
>> should use pointer
>> receiver to avoid big memory copy. This is not a good solution, maybe there 
>> should be a
>> const keyword that stop modification the big struct and avoid big copy.
> 
> People already have a way to avoid a big memory copy: use a pointer
> receiver.  It doesn't seem necessary to have a second way.
> 
> Ian
> 
> -- 
> 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 [email protected] 
> <mailto:[email protected]>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXrdGyYuUvymVyPyrpUujPr5Z0%2B3cxV6tz%3DmRZkHVLisg%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXrdGyYuUvymVyPyrpUujPr5Z0%2B3cxV6tz%3DmRZkHVLisg%40mail.gmail.com>.

-- 
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/856A6094-A1E9-4771-BBFB-D26BEE84E76B%40ix.netcom.com.

Reply via email to