thanks, > 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.
in short and put straightly, 1- i think its not appropriate to let us define pointer/non pointer attribute of a type over multiple points in the code. In my experience of a beginner, its a pain that teaches you to always use pointer by default. 2- The current way to define a type as value/pointer does indeed serves its job, but absolutely nothing more, that is where i feel there are certain lacks. As you say the keyword is superfluous, but not practical imho, in any cases can it be made helpful to help us prevent error or undesired side effects ? Can the compiler helped not to copy a pointer when it is inappropriate. > 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 . I have read both your thoughts and the doc, i have not found a "useful feature". I respectfully did not. (hope the ability of value/pointer is not the feature you talk about because i don t intend to remove it, and its barely just a feature i think, its critical) imho, we should not defines the way the type is stored in memory at its declaration, unless it produces useful barriers to mistakes. So i think there should be only no-star on receiver. And that to the question "where to store that instances" (use pointer or value?) the answer should be provider only at the instanciation time. (see below i have a tech question about it btw, please) The only feature it disables i can think about is the feature which helps to tell if your receiver is nil/or not. I question this feature and wonder if it was a worthy trade against other possibilities, if one wants to imagine them, obviously. Side Q, Given this program, with an hypothetical Value type with a method Hello without side effects. func main(){ x(T{}) } func x(T Value){ (&T).Hello() // How is this happening ? // Does it escape the variable ahead of time so x become x(T *Value) ? // Or does it take the address of T wherever it is in memory to manipulate it ? // or maybe it does a copy of T to new *T, do the work, copies, then frees it ? } thanks again for your time. On Monday, May 8, 2017 at 8:39:48 PM UTC+2, Ian Lance Taylor wrote: > > On Sun, May 7, 2017 at 3:37 AM, <mhh...@gmail.com <javascript:>> 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.
