Sorry, I only brought it up because it seemed related to me, and the original
question was answered as No...
> On Nov 19, 2018, at 6:06 PM, Dan Kortschak
> wrote:
>
> I don't agree that it was a bad idea. It eases reading and writing in
> many cases. The mutability of a value is based on the m
I don't agree that it was a bad idea. It eases reading and writing in
many cases. The mutability of a value is based on the method signature,
which is readily available through the godoc.
On Mon, 2018-11-19 at 17:57 -0600, Robert Engels wrote:
> I understand that. I was stating that the syntactic
I understand that. I was stating that the syntactic sugar of automatic pointer
creation to call a method should be removed. Having an A become a *A in one
instance but not in others just causes confusion, let alone makes things not
obviously mutable, mutable, causing a developer to determine tha
As Axel points out this is not the case. This can be demonstrated by
trying to assign the struct to an interface that has the method you are
wanting to call. The following would compile under the rules you're
suggesting. It doesn't.
https://play.golang.org/p/qRYPaDOPYsl
On Mon, 2018-11-19 at 15:
On Mon, Nov 19, 2018 at 10:37 PM Robert Engels wrote:
> That is not really true though, as I can declare a method that take a pointer
> receiver and mutate through it, but the caller can pass a struct which it
> thinks can not be mutated.
>
> https://play.golang.org/p/Abf4VX9kUTR
This is syntac
That is not really true though, as I can declare a method that take a pointer
receiver and mutate through it, but the caller can pass a struct which it
thinks can not be mutated.
https://play.golang.org/p/Abf4VX9kUTR
Go isn’t type safe by stating that methods cannot mutate structs. Any reader o
The restriction has nothing to do with heaps (in fact, the Go language
(i.e. the spec) doesn't even have a concept of a "heap"). It's a
type-safety requirement. If you pass in a value, it can't be mutated,
full-stop. Reflect shouldn't allow you to bypass type-safety - only
"unsafe" can do that, hen
Interesting. I guess that makes sense. But you would think that if using a
reflection call should force the compiler to heap allocate , then no reason for
the restriction.
> On Nov 19, 2018, at 2:33 PM, Ian Denhardt wrote:
>
> Quoting Robert Engels (2018-11-19 15:13:53)
>> But isn’t that just
Quoting Robert Engels (2018-11-19 15:13:53)
> But isn’t that just for safety. Meaning the unmarshall could use it as a
> pointer via reflection and mutate it (but that is probably not what the
> caller expects in Go) ?
No, see:
https://play.golang.org/p/MyF0Dx87-1j
If you pass in &foo inst
But isn’t that just for safety. Meaning the unmarshall could use it as a
pointer via reflection and mutate it (but that is probably not what the caller
expects in Go) ?
> On Nov 19, 2018, at 2:04 PM, Ian Denhardt wrote:
>
> From an implementation standpoint they are passed by reference (The
>
>From an implementation standpoint they are passed by reference (The
representation is actually a pair (pointer to vtable, pointer to
object), but from a semantic standpoint the difference still matters,
because e.g. if the original value was a struct, it still can't be
mutated. There are use cases
Aren’t all interface references passed as a pointer? It is a var that contains
a pointer to the struct and a concrete type of the struct?
> On Nov 19, 2018, at 8:45 AM, Volker Dobler wrote:
>
> > Is there a way to force "SomeFunction" to take pointers only at compile
> > time?
>
> No, sorry.
> Is there a way to force "SomeFunction" to take pointers only at compile
time?
No, sorry.
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+unsub
13 matches
Mail list logo
