On Sun, May 7, 2017 at 3:37 AM, <mhhc...@gmail.com> wrote: > yes, sorry you scratched your head > > https://play.golang.org/p/Gg6Euyvsw6 > > this example shows that it is possible to do all the things. > hth. > > I m curious to know more about other questions. > Maybe they are not good idea, or not technically achievable. > Just curious.
> if a new keyword appear to ensure a type is > consumed by value, that might be helpful to provide > a function to make sure that type won t exceed the stack size > and escape to the heap. > that keyword would help api designer to avoid consumption problems. > nop ? To me that seems like a very abstract concern. The definition of the method always makes it clear whether you are passing a value of the type or a pointer to the type. People defining methods on large types should know which one want to use. There is no need for an additional keyword; the method definition is clear in any case. > If a new keyword would appear to ensure a type is initialized by reference, > might help to detect value copy and warn/error when that case is met. > That would helped consumers to avoid problems. > nop ? Where would such a keyword be used? The definition of the type makes clear whether it has values or pointers. > If the receiver type was not able to be star/nostar, > that d probably help to get ride of confusion, > nop ? That would lose a clearly useful feature from the language. In particular, if you only permit pointer receivers or value receivers, which one do you permit? See also https://golang.org/doc/faq#methods_on_values_or_pointers . 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 golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
