You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
// An emptyCtx is never canceled, has no values, and has no deadline. It is not
// struct{}, since vars of this type must have distinct addresses.
typeemptyCtxint
Effectively it creates a new type that's supposed to be "empty" using int. I also noticed things like this in my own code.
It does not state the intent clearly, and the implementation is most likely suboptimal.
We could have an empty type instead. The idea is, roughly, for it to be like bool, but with just a single possible value (empty), inspead of two (true/false).
Usage example would look like this:
ch:=make(chanempty)
ch<-empty
What do you think?
PS: I can already see a potnetial issue with the type name and the type value colliding with each other. If we want to move forward with this we should be able to solve it.
The text was updated successfully, but these errors were encountered:
It's not clear though why that code from context package I linked as an example uses int instead of struct{}. Can anyone explain the comment, and what the author meant by mentioning the requiement to have distinct addresses? How int is different from struct{}? This may be relevant to this proposal, but don't know if it really is.
The two scenarios you mention are unrelated. The first is due to the following in the spec:
A struct or array type has size zero if it contains no fields (or elements, respectively) that have a size greater than zero. Two distinct zero-size variables may have the same address in memory.
The second is a common way to create a "signal" channel where data is not needed.
ch:=make(chanstruct{})
close(ch) // Any <-ch gets unblocked
If you add a new built-in type called empty, you would need it to be a non-zero size in the first scenario, and preferably zero-sized in the second (but not required).
I think I'd need empty type to be zero size at all times - so that the values have the same memory address. Though, it seems struct{} already does just that.
And now I see why int is used - it's rather unobvious though. It makes perfect sense when you look at the language doc, but in this case it just didn't click for me. Thanks for making it clear, @bontibon.
So, in fact, I agree, and adding an empty type would not make sense - for the not-so-easy to grasp usecases where one actually want non-zero values just to make sure the pointer addresses will be different it's ok to use an int, and for the second case - which is much more common - to use struct{}.
I think I'll close this, please reopen if it's too early.
I stumbled upon this code recently:
go/src/context/context.go
Lines 167 to 169 in 4330866
Effectively it creates a new type that's supposed to be "empty" using
int
. I also noticed things like this in my own code.It does not state the intent clearly, and the implementation is most likely suboptimal.
We could have an
empty
type instead. The idea is, roughly, for it to be likebool
, but with just a single possible value (empty
), inspead of two (true
/false
).Usage example would look like this:
What do you think?
PS: I can already see a potnetial issue with the type name and the type value colliding with each other. If we want to move forward with this we should be able to solve it.
The text was updated successfully, but these errors were encountered: