Mike,
Correction: FAQ s/b CodeReviewComments
peter
On Thursday, September 26, 2024 at 7:08:25 AM UTC-4 peterGo wrote:
> Mike,
>
> The Go FAQ begins with "Go interfaces generally ...".
>
> Go documentation is written in American English.
>
> generally adverb
>
> : in a general manner: such as
>
Mike,
The Go FAQ begins with "Go interfaces generally ...".
Go documentation is written in American English.
generally adverb
: in a general manner: such as
a : in disregard of specific instances and with regard to an overall
picture generally speaking
b : as a rule : usually
https://www.mer
I don't believe this is contradictory. TL;DR: `error` is a (very) special
case, part of the language specification itself.
Long-form (my take):
The guidance in CodeReviewComments relate to interface types and any
implementation defined by a project.
The guidance in faq#nil_error relates to c
Sorry to revive this, but I'd like to add to conversation (without weighing
in on correctness of the nil check) that it appears the CodeReview comments
on interfaces ( https://go.dev/wiki/CodeReviewComments#interfaces ) and the
FAQ nil error https://go.dev/doc/faq#nil_error give mutually exclus
On Wed, Sep 2, 2020 at 3:45 AM targe...@gmail.com wrote:
>
> > Other people have said this too, but I want to emphasize that there
> are not 4 potential states of an interface value. There are 2
> potential states: 1) interface does not hold any value, and is == nil;
> 2) interface holds a value,
The clarifying question first:
What would be the meaning of "none" interface?
>
A `none` interface would be the zero value of an interface - an interface
value with no dynamic type/value.
It doesn't solve issue at hand. The issue is, conversion from typed nil
> pointer to interface results in no
> I gave you a third solution: Having a separate identifier for the zero
value of interfaces.
It doesn't solve issue at hand. The issue is, conversion from typed nil
pointer to interface results in non-nil interface with valid vtable pointer
and nil receiver. And only limited set of specifical
> Other people have said this too, but I want to emphasize that there
are not 4 potential states of an interface value. There are 2
potential states: 1) interface does not hold any value, and is == nil;
2) interface holds a value, and is != nil.
Indeed, there are 2 states of interface observab
Maybe I misunderstood this
>
> The first is the old adage: "Accept interfaces return concrete types."
No interface based design would have you declare a concrete type as the return
value - so it must be declaring a interface return and returning a concrete.
Which is what was being argued aga
On Thu, Aug 27, 2020 at 3:53 AM targe...@gmail.com wrote:
>
> Please don't forget that interface pointer isn't simple. It's a so-called
> "fat pointer" which consists of pointer to data and pointer to methods table.
> Thus, we have 4 potential states - (nil, nil), (nil, pointer), (pointer, nil)
On Thu, Aug 27, 2020 at 12:27 PM Robert Engels wrote:
>
> I think you just made the case... if you have existing code that declares a
> concrete return type and you change that to an interface and nothing else you
> are going to have problems.
I don't think anybody said "..change it to interfac
I think you just made the case... if you have existing code that declares a
concrete return type and you change that to an interface and nothing else you
are going to have problems.
> On Aug 27, 2020, at 12:11 PM, Jake Montgomery wrote:
>
>
>
>
>> On Thursday, August 27, 2020 at 10:45:52
On Thursday, August 27, 2020 at 10:45:52 AM UTC-4, burak serdar wrote:
>
> On Thu, Aug 27, 2020 at 6:12 AM 'Axel Wagner' via golang-nuts
> > wrote:
> >
> > On Thu, Aug 27, 2020 at 12:53 PM targe...@gmail.com > wrote:
> >>
> >> Because you then must remember about this specific case every ti
* targe...@gmail.com [200827 05:40]:
> On Thursday, August 27, 2020 at 12:20:59 PM UTC+3 axel.wa...@googlemail.com
> wrote:
>> I'm saying the current situation is less confusing than what you
>> describe, yes.
>>
>> AIUI, with what you describe, if I have a variable `x` of type `*T`
>> and an int
On Thu, Aug 27, 2020 at 6:12 AM 'Axel Wagner' via golang-nuts
wrote:
>
> On Thu, Aug 27, 2020 at 12:53 PM targe...@gmail.com
> wrote:
>>
>> Because you then must remember about this specific case every time you cast
>> potentially nil pointer variable to interface. Every time you must write `if
(whoops: "I don't run into cases […] very often")
On Thu, Aug 27, 2020 at 2:12 PM Axel Wagner
wrote:
> On Thu, Aug 27, 2020 at 12:53 PM targe...@gmail.com
> wrote:
>
>> Because you then must remember about this specific case *every time *you
>> cast potentially nil pointer variable to interface
On Thu, Aug 27, 2020 at 12:53 PM targe...@gmail.com
wrote:
> Because you then must remember about this specific case *every time *you
> cast potentially nil pointer variable to interface. Every time you must
> write `if x != nil { return x; } else { return nil; }` instead of just
> `return x;`
>
> And for different types this is pretty normal as you can have
>x == 0.2 // true
>y = int(x)
>float64(y) != 0.2 // true too
A more correct analogy would've been:
var x := 0.2
var y := float32(x)
math.IsNaN(float64(y)) // true in this analogy
> It is a property of all
On Thursday, 27 August 2020 11:39:11 UTC+2, targe...@gmail.com wrote:
>
> To me, if `x == nil` and then `y != nil` after `y = x` is much more
> confusing.
>
This can happen only if x and y have different types.
And for different types this is pretty normal as you can have
x == 0.2 // true
“Tip” of course :)
> On Aug 27, 2020, at 6:03 AM, targe...@gmail.com wrote:
>
>
> > I'm mostly form C++ land
> from of course :)
>
>> On Thursday, August 27, 2020 at 2:01:33 PM UTC+3 targe...@gmail.com wrote:
>> I know this. I'm mostly form C++ land, so you may imagine how many warts are
>>
> I'm mostly form C++ land
from of course :)
On Thursday, August 27, 2020 at 2:01:33 PM UTC+3 targe...@gmail.com wrote:
> I know this. I'm mostly form C++ land, so you may imagine how many warts
> are there "on the top of the index finger" :)
> I'm merely speaking against opinion that Shroeding
I know this. I'm mostly form C++ land, so you may imagine how many warts
are there "on the top of the index finger" :)
I'm merely speaking against opinion that Shroedingerface is not a problem
at all.
On Thursday, August 27, 2020 at 1:55:54 PM UTC+3 ren...@ix.netcom.com wrote:
> This will be a G
This will be a Go wart that will never go away. All languages have warts. This
one just happens to be on the top of the index finger There is so little
utility in a nil interface but it’s there.
> On Aug 27, 2020, at 5:14 AM, 'Axel Wagner' via golang-nuts
> wrote:
>
>
>
>> On Thu, Aug 27
> Even though I really don't understand why this isn't just one of those
"you learn about it, you know about it, you never run into any problems
again" type of things.
Because you then must remember about this specific case *every time *you
cast potentially nil pointer variable to interface. Ev
On Thu, Aug 27, 2020 at 11:39 AM targe...@gmail.com
wrote:
> > I'm saying the current situation is less confusing than what you
> describe, yes.
> > AIUI, with what you describe, if I have a variable `x` of type `*T` and
> an interface variable `y`, then `y = x` and `y = (*T)(x)` have different
>
> I'm saying the current situation is less confusing than what you
describe, yes.
> AIUI, with what you describe, if I have a variable `x` of type `*T` and
an interface variable `y`, then `y = x` and `y = (*T)(x)` have different
semantics. I think it is strange to have a conversion of `x` *to i
On Thu, Aug 27, 2020 at 11:10 AM targe...@gmail.com
wrote:
> it would definitely. Though price for consistency looks very much
> acceptable.
I don't think "consistency" is at all the right word here. If anything,
things would get *less* consistent, not more.
> Personally, I would also find it
> This would require to insert extra nil-checks when assigning a
pointer-value to an interface, as the compiler can't know if a pointer is
nil or not.
it would definitely. Though price for consistency looks very much
acceptable.
> Personally, I would also find it very confusing, if converting
On Thu, Aug 27, 2020 at 10:06 AM targe...@gmail.com
wrote:
> Not sure if it was mentioned here, but IMO the main issues isn't nil data
> itself, but how easy it's created. It'd be much less of a surprise if
> creating nil-data required explicit cast from nil struct pointer to
> interface pointer
Not sure if it was mentioned here, but IMO the main issues isn't nil data
itself, but how easy it's created. It'd be much less of a surprise if
creating nil-data required explicit cast from nil struct pointer to
interface pointer and resulted in just nil interface pointer in case of
implicit ca
Can we at least move with the https://github.com/golang/go/issues/22729 ,
please? Anything will help with the current mess.
On Sunday, August 23, 2020 at 8:52:30 PM UTC-7, Ian Lance Taylor wrote:
>
> On Sun, Aug 23, 2020 at 1:16 PM Denis Cheremisov
> > wrote:
> >
> > You may use something like
On Sun, Aug 23, 2020 at 1:16 PM Denis Cheremisov
wrote:
>
> You may use something like this
>
> value2 := *(*uint64)(unsafe.Pointer(uintptr(unsafe.Pointer(&value)) +
> 8))
> if value2 == 0 {
> return true
> }
>
> on AMD64, should work also for any 64 bit ar
You may use something like this
*value2 :=
*(*uint64)(unsafe.Pointer(uintptr(unsafe.Pointer(&value)) + 8))*
*if value2 == 0 {*
*return true*
*}*
on AMD64, should work also for any 64 bit architecture (at least I believe
so). Remember though this is hacky
I was trying to show that the current behavior is confusing and that
fmt.Print() needing to resort to panic-and-recover is kinda code smell, but
I sorts-of convinced myself that the current behavior is right, or at least
consistent.
In my code, I got bit because I sometimes use v *Type to denot
I agree with the OP. The usefulness of nil interfaces is pretty limited. Show
me a useful case that cant easily be implemented with non-nil interfaces.
I would argue that allowing nil interfaces causes more subtle latent bugs and
makes it harder to reason about the correctness of code when revi
On Fri, Apr 10, 2020 at 7:17 PM wrote:
> I realize I'm reviving an age-old discussion here and apologize for
> bringing up the undead. I happend to run into this when my application
> panicked when some interfaces where initialized with nil mock objects
> instead of being left uninitialized as in
Yes, Ayan, you are quite correct. There are a lot of comparisons to check
if an error is nil. It has it's own FAQ entry:
https://golang.org/doc/faq#nil_error
Sincerely, what I am after is an example of a situation where the solution
proposed by Dave Cheney would create a problem, like "See here
On 11/03/2017 05:23 AM, oju...@gmail.com wrote:
> Could somebody please point me to any example of comparing an
> interface to nil, in production code? Thanks.
>
Does checking if a variable of type error is nil count?
-ayan
--
You received this message because you are subscribed to the Googl
On Wednesday, 1 November 2017 12:19:19 UTC+1, JuciÊ Andrade wrote:
>
> Ayan, imagine I am part of a development team. In our program I have a
> pointer r:
>
> r *myType
>
> My variable r can be nil, because that is a valid situation. It is used in
> dozens of places, like this:
>
> if r != nil {
On Wednesday, November 1, 2017 at 10:32:21 AM UTC-4, Ian Lance Taylor wrote:
>
> On Wed, Nov 1, 2017 at 4:18 AM, > wrote:
> >
> > Ayan, imagine I am part of a development team. In our program I have a
> > pointer r:
> >
> > r *myType
> >
> > My variable r can be nil, because that is a valid
It seems a very bad idea, to require the common case to go through some
package or else get lint-warned.
Checking "x == nil" is the correct way to check whether a value contains a
valid implementation of an interface - and a nil-pointer with the correct
method set is, as far as you should be conce
On 11/01/2017 09:31 AM, Ian Lance Taylor wrote:
On Wed, Nov 1, 2017 at 4:18 AM, wrote:
Ayan, imagine I am part of a development team. In our program I have a
pointer r:
r *myType
My variable r can be nil, because that is a valid situation. It is used in
dozens of places, like this:
if r !
On Wed, Nov 1, 2017 at 4:18 AM, wrote:
>
> Ayan, imagine I am part of a development team. In our program I have a
> pointer r:
>
> r *myType
>
> My variable r can be nil, because that is a valid situation. It is used in
> dozens of places, like this:
>
> if r != nil {
> r.doSomething()
> }
>
On Wednesday, November 1, 2017 at 3:37:54 PM UTC+2, Ayan George wrote:
>
>
>
> On 11/01/2017 07:18 AM, oju...@gmail.com wrote:
> > Ayan, imagine I am part of a development team. In our program I have a
> > pointer r:
> >
> > r *myType
> >
> > My variable r can be nil, because that is a vali
On 11/01/2017 07:18 AM, oju...@gmail.com wrote:
> Ayan, imagine I am part of a development team. In our program I have a
> pointer r:
>
> r *myType
>
> My variable r can be nil, because that is a valid situation. It is used
> in dozens of places, like this:
>
> if r != nil {
> r.doSomethin
Ayan, imagine I am part of a development team. In our program I have a
pointer r:
r *myType
My variable r can be nil, because that is a valid situation. It is used in
dozens of places, like this:
if r != nil {
r.doSomething()
}
That is a very usual idiom, no only in Go, but in many langua
On 10/31/2017 12:42 PM, oju...@gmail.com wrote:
> Today you can't, Ayan.
>
Right -- I understand that. I'm asking how would you propose Go do
that? What changes would you make to fix this?
I'm asking: If you claim Go is fundamentally broken in this way, how
would you fix it?
-ayan
--
You
On Wed, Nov 1, 2017 at 3:42 AM, wrote:
> Today you can't, Ayan.
>
It's very consistent, you can't compare an interface value reliably to
any untyped constant.
Because there is no way for the compiler to figure out what type it should take.
https://play.golang.org/p/4Fn0YNE2md
--
You received
On Tue, Oct 31, 2017 at 5:33 PM, wrote:
> The internal layout Go uses to store an interface should not mess with the
> expected behavior.
>
If interface is two separate fields, or just a pointer, or refers to a
> bitmap stored on the Moon, I don't care. I shouldn't care.
And you don't have to c
* oju...@gmail.com [171031 12:34]:
> Ian, with all due respect, I beg to differ.
>
> Let's look at that example posted 5 years back:
>
> http://play.golang.org/p/Isoo0CcAvr
>
> Yes, that is the proper behavior according to the rules, we have a FAQ
> entry, fine, but ... put simply: that makes
I am not sure what exactly is the issue you are complaining about. You can
think of interface as a container for some data type. The container can be
nil and the data contained in it can be nil. This looks reasonable to me as
much as having a C++ vector that contains nil (well, nullptr) pointers.
Today you can't, Ayan.
On Tuesday, October 31, 2017 at 12:34:44 PM UTC-2, Ayan George wrote:
>
>
>
> On 10/31/2017 10:25 AM, oju...@gmail.com wrote:
> > Not being able to test for a nil interface is a Go language bug.
> >
>
> Just curious: How would you do this without type assertion or refle
Ian, with all due respect, I beg to differ.
Let's look at that example posted 5 years back:
http://play.golang.org/p/Isoo0CcAvr
Yes, that is the proper behavior according to the rules, we have a FAQ
entry, fine, but ... put simply: that makes no sense. Why? Because we, the
users, expect the co
On Tue, Oct 31, 2017 at 7:25 AM, wrote:
>
> Not being able to test for a nil interface is a Go language bug.
>
> Humans are fallible, so are our projects. Every project has its share of
> errors.
> Go, despite being a great tool we all love, is no exception to that
> universal rule.
Agreed about
On 10/31/2017 10:25 AM, oju...@gmail.com wrote:
> Not being able to test for a nil interface is a Go language bug.
>
Just curious: How would you do this without type assertion or reflection?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To
55 matches
Mail list logo
