Re: [go-nuts] why received can be defined with/without pointer?

[Volker Dobler]

I must admit you lost me.

Thus just some minor notes:

On Tuesday, 9 May 2017 16:05:16 UTC+2, mhh...@gmail.com wrote:
>
>
> Help me to not copy a pointer value when its inappropriate.
>

Copying a pointer value is one of the most trivial and fast operations
imaginable.
Maybe you are using the term "pointer value" in some non-standard way here?
 

> If there s a purpose at defining star/nostar on a type,
> but not mix them either,
> help me to make that happen with ease, rather than pain.
>  
> That is, i agree there s point in defining star/nostar like property on a 
> type,
> (note i don t speak of receiver at purpose), see below.
>

Maybe this is part of the confusion. The current language (as opposed
to some other hypothetical language, probably better discussed on
some other mailing list) has no star or nostar properties on types.
Some types carry methods. Some don't. Some types are intimately
related like *T and T and share methods.
 

> yes. The consumer can decide how to consume the value,
> according if its provided/defined type is star/nostar.
>
> //defined
> var x {} // put on heap
> var x T // put on stack
>

This is definitely a misconception: Allocation on heap vs stack is
totaly unrelated to value methods vs pointer methods. Both examples
might be allocated on the stack or on the heap and this depends
on other factors than methods of T.
 

>
> // provided
> //func (r Value) n(x T) {().Hello()} // x passed from stack (there might 
> be some magic here, not the point, i think)
> //func (r Value) n(x *T) {(*x).Hello()} // always get x from heap
> //func (r Value) n(x InterfaceDef){x.Hello()} // x is pointer to value 
> that matches intf.
>

None of these explanations are accurate.
 

>
> Why does it matter that the declarer knows about this in its receiver ? 
> I can t find much examples about that, besides testing if the receiver is 
> nil.
>
> That the declarer defines a type to be handled by copy 
> needs proper out values,
> not only nostar def on the receiver,
> does it ?
>

I'm sorry, I do not understand what you are asking.
 

>
> yes, i m really focused about the receiver.
>
> by incidence i come to think about the struct, indeed somehow,
>
> type S ref { a int64; b[3]complex128 } // prevent copy of S
> type S value { a int64; b[3]complex128 } // prevent referencing to S
> type S struct { a int64; b[3]complex128 } // does not matter
>

It would be helpful if you would define what you mean exactly
when you say "prevent copy" or "prevent referencing" as "referencing"
is pretty vague. How would a=b work if b was of "prevent copy" type?


What can i do with `func (x *T)...` i can not do with `func (x T)`,
> except checking for T==nil ?
>

Like explained several times in this thread:
func (x *T) lets you modify *x 

 
>> A "non-star" receiver would be a method on a value
>> (non-pointer, non-interface) type.
>> This would basically disallow methods to mutate the receiver
>> state as only a copy of the receiver would be mutated.
>> Are you proposing that methods on values should not
>> operate on a copy of the value? 
>>
>
> The consumer can tell about it.
>
> If he receives a value `func (x T)` he can say `x.Hello()` or 
> `().Hello()`
> If he receives a pointer `func (x *T)` he can say `x.Hello()` or 
> `(*x).Hello()` 
>
> if he defines `var x T` and do  `().Hello()` is weird.
> if he defines `var x *T` and do  `(*x).Hello()` is weird.
>
>
Again: I have to admit I'm lost and have no idea what you
try to express.
  
Regards

V.

-- 
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] why received can be defined with/without pointer?

[mhhcbon]

On Tuesday, May 9, 2017 at 2:21:52 PM UTC+2, Volker Dobler wrote:
>
> On Tuesday, 9 May 2017 12:30:38 UTC+2, mhh...@gmail.com wrote:
>>
>> 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.
>>
>
> Please keep in mind that while "friendly to newcomers/beginner"
> _is_  important it cannot be the main (or even only) goal of a language
> targeting productivity.
>

I don t intend to, did i, i have not noticed, i want not.
I intent to think about it from my pov.
The how a solution might embrace all those cases expresses,
is subject to debate, if any there should be indeed.
 

>  
>
>> 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. 
>>
>
> What more than "serve[...] its job" would you expect from a
> language construct. Go offers two types of methods, those
> defined on value types and those defined on pointer types.
> Both are useful, both server their job. What's wrong here?
>  
>

Help me to not copy a pointer value when its inappropriate.
If there s a purpose at defining star/nostar on a type,
but not mix them either,
help me to make that happen with ease, rather than pain.
 
That is, i agree there s point in defining star/nostar like property on a 
type,
(note i don t speak of receiver at purpose), see below.


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)
>>
>
> It is useful to have methods on values and it is useful to have
> methods on pointers. Both are useful: Pointer methods make
> mutation possible and value methods provide a notion of 
> const-ness which is useful too and value methods can be invoked
> on non-addressable values which is useful too.
> This type of usefulness might not be obvious on first encounter
> with these two types of methods.
>

yes. The consumer can decide how to consume the value,
according if its provided/defined type is star/nostar.

//defined
var x {} // put on heap
var x T // put on stack

// provided
//func (r Value) n(x T) {().Hello()} // x passed from stack (there might 
be some magic here, not the point, i think)
//func (r Value) n(x *T) {(*x).Hello()} // always get x from heap
//func (r Value) n(x InterfaceDef){x.Hello()} // x is pointer to value that 
matches intf.

Why does it matter that the declarer knows about this in its receiver ? 
I can t find much examples about that, besides testing if the receiver is 
nil.

That the declarer defines a type to be handled by copy 
needs proper out values,
not only nostar def on the receiver,
does it ?



>  
>
imho, we should not defines the way the type is stored in memory
>> at its declaration, unless it produces useful barriers to mistakes.
>>
>
> I'm not sure I understand: Something like
> type S struct { a int64; b[3]complex128 }
> actually defines storage layout and I think that the ability to control
> is this in Go is a good (and useful thing).
>
>
yes, i m really focused about the receiver.

by incidence i come to think about the struct, indeed somehow,

type S ref { a int64; b[3]complex128 } // prevent copy of S
type S value { a int64; b[3]complex128 } // prevent referencing to S
type S struct { a int64; b[3]complex128 } // does not matter

What can i do with `func (x *T)...` i can not do with `func (x T)`,
except checking for T==nil ?


So i think there should be only no-star on receiver.
>>
>  
> A "non-star" receiver would be a method on a value
> (non-pointer, non-interface) type.
> This would basically disallow methods to mutate the receiver
> state as only a copy of the receiver would be mutated.
> Are you proposing that methods on values should not
> operate on a copy of the value? 
>

The consumer can tell about it.

If he receives a value `func (x T)` he can say `x.Hello()` or `().Hello()`
If he receives a pointer `func (x *T)` he can say `x.Hello()` or 
`(*x).Hello()` 

if he defines `var x T` and do  `().Hello()` is weird.
if he defines `var x *T` and do  `(*x).Hello()` is weird.

 This would be possible but

> it would be an exception to the normal rules how values
> are copied during function invocation. 
>

Possibly yes.
 

> Would such an exception
> really make the language easier to understand? 
>

digging.
 

> And if yes:
> We would lose the notion of const-ness and method
> invocation on non-addressable values would be limited.
>
> I think we misunderstood and hope that helps you to find out about it.
or else, hope i can understand your misunderstanding of my questions.
 

>  
>
>> And that to the question "where to store that 

Re: [go-nuts] why received can be defined with/without pointer?

[Jan Mercl]

On Tue, May 9, 2017 at 2:22 PM Volker Dobler 
wrote:

> Go offers two types of methods, those
> defined on value types and those defined on pointer types.

To avoid possible confusion: It's not possible to attach methods to a
pointer type. The receiver has form T or *T, but T cannot be a pointer type.

-- 

-j

-- 
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] why received can be defined with/without pointer?

[Volker Dobler]

On Tuesday, 9 May 2017 12:30:38 UTC+2, mhh...@gmail.com wrote:
>
> 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.
>

Please keep in mind that while "friendly to newcomers/beginner"
_is_  important it cannot be the main (or even only) goal of a language
targeting productivity.
 

> 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. 
>

What more than "serve[...] its job" would you expect from a
language construct. Go offers two types of methods, those
defined on value types and those defined on pointer types.
Both are useful, both server their job. What's wrong here?
 

> 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)
>

It is useful to have methods on values and it is useful to have
methods on pointers. Both are useful: Pointer methods make
mutation possible and value methods provide a notion of 
const-ness which is useful too and value methods can be invoked
on non-addressable values which is useful too.
This type of usefulness might not be obvious on first encounter
with these two types of methods.

imho, we should not defines the way the type is stored in memory
> at its declaration, unless it produces useful barriers to mistakes.
>

I'm not sure I understand: Something like
type S struct { a int64; b[3]complex128 }
actually defines storage layout and I think that the ability to control
is this in Go is a good (and useful thing).

So i think there should be only no-star on receiver.
>
 
A "non-star" receiver would be a method on a value
(non-pointer, non-interface) type.
This would basically disallow methods to mutate the receiver
state as only a copy of the receiver would be mutated.
Are you proposing that methods on values should not
operate on a copy of the value? This would be possible but
it would be an exception to the normal rules how values
are copied during function invocation. Would such an exception
really make the language easier to understand? And if yes:
We would lose the notion of const-ness and method
invocation on non-addressable values would be limited.

 

> 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){
> ().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 ?
> }
>

I have to admit I'm confused and probably do not understand your
question so forgive me if I'm unable to explain it in detail.

In func x(T Value) {...} the T is a copy of the zero Value{} (typo here in
your code?) passed from main.
T is addressable and  is it's address. If T has a method
Hello than *T has also a method Hello. So ().Hello() invokes
Hello on the copy of the zero value created in main.

So it would be the second option: "[...] does it take the address
of T wherever it is in memory to manipulate it ?"

There is not much magic here. Copying happens during invocation of
function x, not during the method call Hello(). Freeing the memory
used by T happens during GC: Once x is done T is unreachable and
will be collected.

You can read the code and spell out what will happen:

func x(T Value)
Read it like: function x takes a copy of a Value and names this copy T

().Hello()
Read it like: Take the address of T and invoke the Hello method from
type *Value. This is the Hello method from type Value as *Value's
method set contains all methods from Value.

I hope this helps a bit.

V.

-- 
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] why received can be defined with/without pointer?

[mhhcbon]

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){
().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,   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.

Re: [go-nuts] why received can be defined with/without pointer?

[Ian Lance Taylor]

On Sun, May 7, 2017 at 3:37 AM,   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.

Re: [go-nuts] why received can be defined with/without pointer?

[Rader Lei]

if a method only defined for a pointer receiver, the compiler will add "*" 
before the caller silently.

Why pointer receiver? Try to change the value of a member. You will know 
the difference.

On Sunday, May 7, 2017 at 6:37:59 PM UTC+8, mhh...@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.
>
>
> On Sunday, May 7, 2017 at 2:55:58 AM UTC+2, Ian Lance Taylor wrote:
>>
>> On Sat, May 6, 2017 at 3:39 AM,   wrote: 
>> > 
>> > Question about the receiver of a func. 
>> > 
>> > It can be defined as star/no star, and consumed as star/nostar. 
>> > 
>> > The understanding i have so far is, 
>> > it let the developer define the memory model he d like to use. 
>> > 
>> > It leads to cases such as 
>> > - define start/nostar on a type 
>> > - consume a stared type as a value 
>> > - consume a value type as a pointer 
>>
>> You are not permitted to define a method on a named type defines as a 
>> pointer type, so I don't understand your cases.  Can you describe them 
>> using actual Go code rather than words? 
>>
>> 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.

Re: [go-nuts] why received can be defined with/without pointer?

[mhhcbon]

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.


On Sunday, May 7, 2017 at 2:55:58 AM UTC+2, Ian Lance Taylor wrote:
>
> On Sat, May 6, 2017 at 3:39 AM,   wrote: 
> > 
> > Question about the receiver of a func. 
> > 
> > It can be defined as star/no star, and consumed as star/nostar. 
> > 
> > The understanding i have so far is, 
> > it let the developer define the memory model he d like to use. 
> > 
> > It leads to cases such as 
> > - define start/nostar on a type 
> > - consume a stared type as a value 
> > - consume a value type as a pointer 
>
> You are not permitted to define a method on a named type defines as a 
> pointer type, so I don't understand your cases.  Can you describe them 
> using actual Go code rather than words? 
>
> 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.

Re: [go-nuts] why received can be defined with/without pointer?

[Ian Lance Taylor]

On Sat, May 6, 2017 at 3:39 AM,   wrote:
>
> Question about the receiver of a func.
>
> It can be defined as star/no star, and consumed as star/nostar.
>
> The understanding i have so far is,
> it let the developer define the memory model he d like to use.
>
> It leads to cases such as
> - define start/nostar on a type
> - consume a stared type as a value
> - consume a value type as a pointer

You are not permitted to define a method on a named type defines as a
pointer type, so I don't understand your cases.  Can you describe them
using actual Go code rather than words?

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.

[go-nuts] why received can be defined with/without pointer?

[mhhcbon]

Hi,

Question about the receiver of a func.

It can be defined as star/no star, and consumed as star/nostar.

The understanding i have so far is,
it let the developer define the memory model he d like to use.

It leads to cases such as 
- define start/nostar on a type
- consume a stared type as a value
- consume a value type as a pointer

Which is quiet confusing for beginners, and me.

While i understand that someone would like to declare
a type is consumed by value, I do not understand the last two cases.
when why they might happen.

Can you explain their value added ?

Thinking further more,

Not speaking about dereferencing a pointer,
but initialization of a type in a way that is undesired to the provider.

The way a type is consumed by value or reference,
is an act of design rules (i add a property on the type that make sure it 
is never copied/referenced)
or an act of consumption, 
the designer did not enforce any rule on the type, i might initialize it as 
star/nostar at convenience.

The fact it is let possible today 
- to not enforce the way a type is manipulated, 
   leads to confusion and error (famous one is https://godoc.org/sync)
- to define at both declaration / usage the star/nostar,
   is confusing, again

so yeah, wondering quiet a lot about that,
and given the fact i do not understand few use cases,
i think this could be better handled.

For example, 

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 ?

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 ?

If the receiver type was not able to be star/nostar,
that d probably help to get ride of confusion,
nop ?

-- 
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.