<p>this caused many null pointer panics in our code.</p>
<hr/>**评论：**<br/><br/>TheMerovius: <pre><p>There is some discussion about const pointers (and the like) in <a href="https://groups.google.com/d/msg/golang-nuts/_XiGWtxhmhE/8iWxTYXCfn0J" rel="nofollow">this thread</a>. It's not clear to me, why the absence of the concept would cause null pointer panics?</p></pre>kl0nos: <pre><p>It's great to get a panic, you know then that you are dereferencing null pointers in your code. In C/C++ you would be lucky to get an segfault. </p></pre>theOtherOtherBob: <pre><p>Yes, I'm also glad when my face doesn't get hit when I fall. But you know what's even better? Not falling in the first place.</p></pre>kl0nos: <pre><p>Then use some access function if you can't live without it ? It will give you the same functionality. Language creators were pretty clear about this - it will not land in Golang. You have panics = you know where YOU made a mistake, fix it and problem solved. </p></pre>theOtherOtherBob: <pre><blockquote>
<p>Then use some access function if you can't live without it ? It will give you the same functionality.</p>
</blockquote>
<p>No, it won't give you a static guarantee like a non-nullable reference would.</p>
<blockquote>
<p>You have panics = you know where YOU made a mistake</p>
</blockquote>
<p>No, you don't. You <em>potentially</em> know where you made a mistake <em>sometime later on</em> when the program is run, which <em>may</em> be during tests <em>if you're lucky</em> but it also may be days, weeks, months, years later, potentially in production or on someone else's machine, etc. It is called <a href="https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions" rel="nofollow">The billion-dollar mistake</a> for a reason.</p>
<p>I prefer to know about my mistake as soon as possible, preferably right now on my machine, preferably before the program even has a chance to run and cause damage.</p>
<p>Of course, there's a never-ending debate on how many static guarantees are enough. Type systems can get arbitrarily complex. However, I don't think this applies to non-null pointers much, given how incredibly huge the number of problems with nullable pointers & references has been historically (and not just in C/C++ but in memory-safe languges as well) and because non-nullable references aren't hard to understand or use. Having non-nullable references should be a no-brainer. However, nullable pointers are very deeply rooted in the mainstream culture and heritage of languages like C, Java and others, and so unfortunatelly they feel "natural" to most people even though they are in fact quite silly if you think about it independently of the said heritage.</p>
<blockquote>
<p>it will not land in Golang</p>
</blockquote>
<p>I know, Golang is pretty anti-type-systems. Oh well.</p></pre>pdffs: <pre><p>Lack of const pointers didn't cause panics in your code, poor code caused panics in your code.</p></pre>fix3r: <pre><p>Oh wow, give this man a cigar for the least useful comment in the history of programming.</p></pre>circajerka: <pre><p>Cmon man, it's common sense - Every single program would be perfect if developers would just write perfect code! /s</p></pre>marksteve4: <pre><p>you can argue this for any language. When it comes to a giant industry level project. The language can offload the mental burden of developers would be the best.</p></pre>hell_0n_wheel: <pre><p>This language does a lot to offload mental burdens. Garbage collection, for one. Functions as a first class object, for another. What exactly is so burdensome about this?</p></pre>: <pre><p>[removed]</p></pre>hell_0n_wheel: <pre><p>If you have a point to make, you can do so without the tone. You're also encouraged to add to the conversation, as opposed to whatever it is you're doing here.</p></pre>Macrobian: <pre><p>I'm adding to the discussion by ridiculing the fact that you offered some of the oldest developments of PLT as Go reducing the burden on programmers, in response to an individual being burdened by deficiencies elsewhere in the language. </p>
<p>People expect a little more from a language than features available in Scheme 48 years ago. </p></pre>marksteve4: <pre><p>as one example, I need to make sure there is no another goroutine reassign the pointer.</p></pre>hell_0n_wheel: <pre><p>You can't call golang burdensome, if you're gonna use it to write bad code.</p>
<p>There are simple ways to avoid exactly what you're talking about, without using <code>const</code>. You could avoid this whole situation altogether, if you're a little more careful about how you design your code...</p></pre>marksteve4: <pre><p>mind share how to prevent this without using const? that would benefit every go programmer</p></pre>hell_0n_wheel: <pre><p>You want me to debug your code, even though you're not bothering to share it? That's almost as ridiculous as modifying a shared pointer in a goroutine. </p></pre>freman: <pre><p>*nil</p></pre>allowthere: <pre><p>Generally, Go doesn't seem to be fond of constant anything (except for compile-time constants), and the reason is that it's often hard to reason about constants. For example, </p>
<pre><code>final A a = new A();
</code></pre>
<p>So you would say "Well, <code>A</code> is a constant. But while the variable A is constant, what A points to isn't (and if you're not in Java, you can do something like</p>
<pre><code> var final a = NewA(false);
var b = &a
</code></pre>
<p>Would you be able to do</p>
<pre><code> (*b) = NewA(true)
</code></pre></pre>theOtherOtherBob: <pre><blockquote>
<p>and the reason is that it's often hard to reason about constants</p>
</blockquote>
<p>Constants aren't hard to 'reason about' when they are actually, you know, constant. That is, when they provide actual immutability guarantees that apply recursively.</p>
<p>This is not the case in Java, as it doesn't really support constness / immutability. Your criticism definitely applies to Java's <code>final</code> thingy, which is pretty much useless, but not to immutability in general, which should be pretty easy to 'reason about', in fact, the whole point of immutability is to make things easier to 'reason about'.</p>
<p>Btw. why is 'reasoning about things' such a catchphrase these days?</p></pre>tarantulus: <pre><blockquote>
<p>why is 'reasoning about things' such a catchphrase these days?</p>
</blockquote>
<p>"I don't understand this thing, because I've not been willing to put the effort in to understand it" == "This is hard to reason about".</p></pre>ryeguy: <pre><p>I've never used generics and I've never missed them.</p></pre>theOtherOtherBob: <pre><p>"I find your comment elegant, efficient, and easy to reason about"</p>
<p><sup>= "I agree."</sup></p></pre>irqlnotdispatchlevel: <pre><p>You can not assign the address of a constant to a non-const.</p></pre>RoughMedicine: <pre><p>You picked the worst possible example to talk about constants. Java's <code>final</code> isn't even a proper constant anyway, it just means that that reference will always point to the same value.</p>
<p>You could have talked about C++'s <code>const</code>. If a variable is <code>const</code>, you can't take a non-<code>const</code> pointer to it, so your second example wouldn't work (if you replaced <code>var</code> with <code>auto</code> and <code>final</code> with `const, of course).</p>
<p>C++ also gives you <code>const</code>methods, so you can reason about which methods you can call on an <code>const</code> object (because they won't change it), and which you can't.</p>
<p>So no, constants are not hard to reason about. They're the opposite. When they are real constants (not Java's <code>final</code>) they give you a strong guarantee: this object will never change. That's it. How could that possibly be harder than mutability?</p></pre>theOtherOtherBob: <pre><p>Nit: In C++, it being true to its nature, it's possible to back-stab <code>const</code> guarantees with <code>mutable</code> or casts. But at least both of those are fairly easy to spot in code...</p></pre>0xjnml: <pre><pre><code>package ref
type Int struct{ *int }
func NewInt(p *int) Int { return Int{p} }
func (i Int) Int() int { return *i.int }
</code></pre></pre>
