type Pet struct {
name string
kind string
}
type Person struct {
name string
age int
friends []Person
pet Pet
}
// Current Go
var person1 Person // { name: "", age: 0, friends: [], pet: <nil> }
var person2 *Person // <nil>
// Assuming the zero value of a pointer is a pointer to the zero value of what it points to, then:
var person1 Person // { name: "", age: 0, friends:[], pet: &{ name: "", kind: "" } }
var person2 *Person // &{ name: "", age: 0, friends:[], pet: &{ name: "", kind: "" } }
and the pointer itself would lose the nice property of being a zeroed chunk
of memory (it wouldn't be a zero value).
--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/e2969605-f82f-4b38-a390-87539c9f3041%40googlegroups.com.
I see it is a nice property, but I'd say only for people writing the compiler. I adventure [sic] to say that people using the language won't care too much about this property. Having a useful zero-value (in this case, an initialized pointer), like we have with strings for example, would be a very nice property for language users
if s != nil {
/* initialize struct or inform it is nil */
}
It's also worth pointing out that a nil pointer value can still be useful. You can still call methods on it.
On Sat, 15 Feb 2020, 13:13 , <klos...@gmail.com> wrote:
Woah! that's a killer reason, the one I was searching for. Thanks for pointing it out, as you have saved me a lot of time discarding the proposal I had in mind.--I will need to go in other direction.
El viernes, 14 de febrero de 2020, 15:52:07 (UTC), Brian Candler escribió:In addition, consider: how would you implement the zero default when the type is self-referential? For example:type Treenode struct {left *Treenoderight *Treenode}var Tree1, Tree2 *TreenodeAlso consider deeply nested types which include pointers to structs which contain pointers etc.You can design a language where pointers can never be nil - but then you have to deal with "does not point to anything" some other way (e.g. Maybe values). That ends up with a very different language.
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 golan...@googlegroups.com.
Out of curiosity: Could you please tell when calling methods on nil pointers is useful?
--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHAfA97soJy1iXea1H7Bkv_VO%3D43cLY96zi%2BZ7R0a%3DbTQ%40mail.gmail.com.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/929dfda3-36e3-4bd1-85cb-47f55b6b1e11%40www.fastmail.com.
Well, other languages use the optional/maybe type. It handles sentinel values pretty well and I don't think they bring new kind of bugs (while they remove the nil-pointer related bugs).
> type Treenode struct {> left *Treenode> right *Treenode> }One could of course design a language where Treenode is called cons and left is called car and right is called cdr and (car nil) is nil and (cdr nil) is nil. You could implement such a language by putting 2 words of 0 at location 0 and add a write barrier or page protection to enforce nil immutable.
--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/7199346c-36c8-46ba-97d3-d3ceec6632c1%40googlegroups.com.
The CPU does not care how humans call the abstraction. It has still to
do the same old thing: check some value for being equal/not equal to a
sentinel value or check a tag value for the same effect. That means
additional cost wrt to memory consumption. Additionally, now the
compiler may enforce the check everywhere when humans may know better.
So it buys more safety, undeniably, but as always, there are no free
lunches.
I'd say that's not solving the problem, but making it bigger. Do not
recover from nil panics, instead fix the nil dereference bug and avoid
the panic completely.
--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/e6c9b79c-bf3a-413f-8a79-063a3e1da271%40googlegroups.com.
The problem with that reasoning is that you could use it for anything and then we would never improve any programming language or create others. Ideally, the compiler will catch all the bugs it possibly can so that the programmer can spend the thinking energy on resolving the problem.
I'd say that's not solving the problem, but making it bigger. Do not
recover from nil panics, instead fix the nil dereference bug and avoid
the panic completely.It is never that easy in a medium to big application with a 10+ people team working on it.
For example, Go could have perfectly followed the same approach as C for the arrays: rely on the user to pass the length everywhere and forget about protecting against out-of-bounds accesses. The designers decided not to do so, and thanks to that, you can forget about memory corruption and focus on what matters.
[...]
But if you create wood houses for people, you don't even think of using a hammer! You will use a much more reliable tool. Or if you use it, it will probably be the best hammer in the market, with a perfect weight balance, with an amazingly ergonomic handle, etc.
I see in a programming language as my most important tool. I use it every single day to make a living. It is because of that importance that I want me (and my team) to be as efficient as possible when working with it, so every detail matters a lot. When you create small short-living applications, it is ok if the language is not perfect.
It is because I like so much the way Go approaches programming that I would love to polish those edges that, in my opinion, do make a difference.
--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/6bb009a2-a63e-4a76-a8d6-3d6c1287f78b%40googlegroups.com.