Re: [go-nuts] How to know if interface{} data is nil w/o reflecting?

On Tue, May 8, 2018 at 6:17 PM, Michael Cohen wrote: > > It seems to me that the compiler should at least warn when someone is > comparing an interface to nil (or maybe the linter should warn). It does not > seem that this could ever be what you actually want and it is always

Re: [go-nuts] How to know if interface{} data is nil w/o reflecting?

Thanks Ian for the thorough explanation - again I apologize for asking noob questions :-). The issue in this case was this error: panic: value method github.com/shirou/gopsutil/process.Process.String called using nil *Process pointer which seems to be coming from the go runtime itself.

Re: [go-nuts] How to know if interface{} data is nil w/o reflecting?

On Tue, May 8, 2018 at 7:19 AM, Michael Cohen wrote: > > Well no - the error I get is that I am attempting to call String() method on > a null receiver - so the caller just passed me a regular nil object. The > issue is that I am trying to make a generic polymorphic function

Re: [go-nuts] How to know if interface{} data is nil w/o reflecting?

> On 8 May 2018, at 16:19, Michael Cohen wrote: > > Well no - the error I get is that I am attempting to call String() method on > a null receiver - so the caller just passed me a regular nil object. They passed you a totally legit fmt.Stringer which then panicked when

Re: [go-nuts] How to know if interface{} data is nil w/o reflecting?

Well no - the error I get is that I am attempting to call String() method on a null receiver - so the caller just passed me a regular nil object. The issue is that I am trying to make a generic polymorphic function which should be able to handle whatever is thrown at it - so I guess reflect is

Re: [go-nuts] How to know if interface{} data is nil w/o reflecting?

On 8 May 2018, at 15:26, scude...@gmail.com wrote: But this crashes when foo is really a nil pointer to a type which does support Stringer. The crash isn’t on “your” side though, it’s presumably inside the String() method. Hence, the caller passed you something

Re: [go-nuts] How to know if interface{} data is nil w/o reflecting?

I was responding to the case where one is passed an interface, expects it to contain a typed value, and it does not. --dave -- 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

Re: [go-nuts] How to know if interface{} data is nil w/o reflecting?

I don't understand this comparison. The C idiom you mention is concretely typed (i.e. C doesn't have interfaces, so it doesn't have dynamic types), so I fail to see what it has to do with interfaces. And it makes *far* more sense to check if you got passed a nil-pointer, than to check the concrete

Re: [go-nuts] How to know if interface{} data is nil w/o reflecting?

Drifting back toward the original subject, I'm reminded of the non-bsd-c idiom of char *foo(char *p) { if (p != NULL && *p != NULL) { return some string operation... } ... It seems logical to check the type of the contents of an interface type, and its presence in a function

Re: [go-nuts] How to know if interface{} data is nil w/o reflecting?

Since an interface can be nil I’ve been assuming interface behaves like slice with a pointer to the concrete data within a reference struct (that also includes the data type) which is passed around as an interface var. This playground shows that the interface var is a similar reference type to

Re: [go-nuts] How to know if interface{} data is nil w/o reflecting?

I don't know what you mean by "reference type" - as I understand it, that's not a meaningful phrase in Go. Did you mean "interface"? If so, we store pointers in interfaces all the time in Go. When we set an interface variable i to x, we are semantically making a copy of x and storing it in i. We

Re: [go-nuts] How to know if interface{} data is nil w/o reflecting?

Storing a pointer in a reference type seems absurd to me. Matt On Friday, December 29, 2017 at 11:07:31 PM UTC-6, Matt Harden wrote: > > I really wish Go had not chosen to propagate Hoare's billion-dollar > mistake. I do realize it's all tied up with the idea that initialization is > cheap and

Re: [go-nuts] How to know if interface{} data is nil w/o reflecting?

I really wish Go had not chosen to propagate Hoare's billion-dollar mistake. I do realize it's all tied up with the idea that initialization is cheap and zero values should be useful when possible, and therefore pointers, interfaces, channels, etc. need zero values. I wonder how different Go

Re: [go-nuts] How to know if interface{} data is nil w/o reflecting?

This thread helped me to understand better the current scenario and the implications of a future change. I would be glad to recognize if this conversation had changed my mind, but it didn't. Some programmers discovered that they could use this "valid nil interface" to do some smart tricks, as

Re: [go-nuts] How to know if interface{} data is nil w/o reflecting?

I often do nil checks on interfaces in places like constructors that may or may not have received optional parameters. In some cases as a parameter that may be nil if no implementation is required, in some cases where a functional option setting the interface was not given. Typically this looks

Re: [go-nuts] How to know if interface{} data is nil w/o reflecting?

On Tue, Oct 31, 2017 at 2:25 AM, wrote: > I found this a little bit non sequitur - if I want to call interface > function I have a perfect business to check if underlying object is not nil > before call just to avoid panic on call. Besides underlying nil in interface > may be

Re: [go-nuts] How to know if interface{} data is nil w/o reflecting?

I found this a little bit non sequitur - if I want to call interface function I have a perfect business to check if underlying object is not nil before call just to avoid panic on call. Besides underlying nil in interface may be used to signal condition for variety of types implementing this