I just don't like the implication that these things *haven't* been thought
about, because nobody could be bothered to polish the "rough edges".
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving
Though I think I *do* agree with you on that particular point (zero-value
design), I'd say this argument is rarely a real one. Let me explain myself:
However clever Google's thousands of programmers are, there might be places
for improvement and I personally want people to try and propose
On Wednesday, 19 February 2020 10:59:33 UTC, klos...@gmail.com wrote:
>
> 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,
On Wednesday, 19 February 2020 11:59:33 UTC+1, klos...@gmail.com wrote:
>
> [...]
> 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
Thanks a lot for your response. All your points make sense and I can
understand your point of view. I simply have a slightly different point of
view that my experience has shaped.
I see in a programming language as my most important tool. I use it every
single day to make a living. It is
>
> 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
Code that is subject to null dereferences, it also susceptible to any incorrect dereference - (e.g. look up in a map using the the wrong key (not just type)) - the program may not crash, but produce incorrect results - which is arguably worse.There is no silver bullet to solve bad
>
> 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.
The problem with that
On Tue, Feb 18, 2020 at 1:22 PM Jan Mercl <0xj...@gmail.com> wrote:
>
> 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
>
If you have
type 'a option = None | Some 'a
you have a so-called "lift" where "None" is a new value playing the role
as no-information or "null". This allows you use the full range of 'a
whatever that is, because you glued a new null-value to it.
However, the problem you may face is that a lot
On Tue, Feb 18, 2020 at 12:44 PM wrote:
> Well, other languages use the optional/maybe type.
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.
On Mon, Feb 17, 2020 at 10:11 PM Rick Hudson wrote:
> > 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
On Tuesday, 18 February 2020 12:44:16 UTC+1, klos...@gmail.com wrote:
>
> 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).
>
That is the market claim.
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).
It is true that they can be a bit cumbersome to use and maybe we lose what
you said: *"the nice and cheap HW
On Tue, Feb 18, 2020 at 12:09 PM wrote:
>
> Regarding pointers: For me, point number 2 (and 3) is the key that forces us
> having some way of expressing emptiness in a pointer.
I'd say that nil pointers are not really special. It's just a sentinel
value. And we definitely need some sentinel
Thanks for the example, it is a really good one. At least for me, it is the
first one where I see the real usefulness.
I don't know why, but eventually, I was able to see the parallelism between
maps and slices. All the confusion comes because we have "append" for
slices and not for maps
Regarding pointers: For me, point number 2 (and 3) is the key that forces
us having some way of expressing emptiness in a pointer. I would say that
point 1 could be optimized by the compiler
Regarding interfaces: Yep! nil-interfaces are a different beast. That's the
reason I focused on just one
> 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
That's a very good point:
* A map can contain any type of value
* map[value_not_present] is defined to return the zero value
* If the map contains other maps:
(a) you don't want a new map to spring into life every time you access a
non-existent key - especially not a floating map which isn't
@Sam, hi, yes, that was the point ^^ My example was here to say "ok, so
let's say the first case works because we have made uninitialized maps
work, but how do we handle the second case?"
It was not made to be runnable as is, I just wanted it to be readable :)
Sorry if that was not clear
Le lun.
I think you need to run your example; the behavior is the same: trying
to make an assignment to the non-nested map will panic contrary to what
your comment says.
> panic: assignment to entry in nil map
—Sam
On Mon, Feb 17, 2020, at 10:35, Michel Levieux wrote:
> Hi Kloster08,
>
> In addition to
Hi Kloster08,
In addition to what others have already pointed out, I'd like to bring you
another case that seems problematic to me concerning the construction of a
"usable nil value" for maps, in the sense that a zero-value map could be
written and read right away without any initialization.
On Mon, Feb 17, 2020 at 11:18 AM wrote:
> Out of curiosity: Could you please tell when calling methods on nil
> pointers is useful?
>
In general, linked datastructures - like linked lists or trees. As a
somewhat trivial example, consider this:
https://play.golang.org/p/Y-4aSVLzEFO
Interpreting
A "usable" nil map, i.e. being able to insert into it straight away, I
sympathise with. Remember though that you can't append "in place" to a nil
slice: it returns a new slice object. https://play.golang.org/p/dL-r74C5m_w
I presume you don't want to write the same for maps as you do for
Nil slices are an example of an ideal zero value. When you use them, you
don't need to check for nil -> its zero value is already usable.
Exactly the "slices" case (and the "string" type) is the one inspiring me
to search for more useful zero values for certain types. The two I am
thinking
I thought of this at the beginning, but when I tried to make it work I
realized that I needed to have the following if:
if s != nil {
/* initialize struct or inform it is nil */
}
on every struct method, which eventually defeated the purpose for my use
case.
Out of curiosity: Could you
>
> 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,
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 , 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
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,
Thanks for the response!
and the pointer itself would lose the nice property of being a zeroed chunk
> of memory (it wouldn't be a zero value).
>
I see it is a nice property, but I'd say only for people writing the
compiler. I adventure to say that people using the language won't care too
much
In addition, consider: how would you implement the zero default when the
type is self-referential? For example:
type Treenode struct {
left *Treenode
right *Treenode
}
var Tree1, Tree2 *Treenode
Also consider deeply nested types which include pointers to structs which
contain pointers
On Fri, Feb 14, 2020, at 09:16, kloste...@gmail.com wrote:
> *Could you please let me know the reasons why the zero value of a
> pointer is `nil` instead of a pointer to the zero value of what it
> points to?*
>
> Is it because of performance/memory? Simplicity in the runtime?
The zero value is a
This is a question to get some information before thinking about a possible
proposal regarding zero values.
*Could you please let me know the reasons why the zero value of a pointer
is `nil` instead of a pointer to the zero value of what it points to?*
Is it because of performance/memory?
33 matches
Mail list logo
