<pre><code>byte(344) // constant 344 overflows byte
</code></pre>
<p>but</p>
<pre><code>v := 344
byte(v) // gives 88
</code></pre>
<hr/>**评论：**<br/><br/>dgryski: <pre><p>The section you're looking for in the specification is the section on shift, under Operators:</p>
<blockquote>
<p>The right operand in a shift expression must have unsigned integer type or be an untyped constant that can be converted to unsigned integer type. If the left operand of a non-constant shift expression is an untyped constant, it is first converted to the type it would assume if the shift expression were replaced by its left operand alone.</p>
</blockquote></pre>3264128256: <pre><p>Sorry, I copy pasted directly. It doesn't matter if I use shift operator or not. I've updated the post.</p>
<p>To anyone confused about the parent, my post previously said:</p>
<pre><code>byte(344>>(0*8))
</code></pre>
<p>but </p>
<pre><code>v := 344
byte(v >> (0*8))
</code></pre></pre>dgryski: <pre><p>Ah, then you want the section under 'Constants' that says</p>
<blockquote>
<p>The values of typed constants must always be accurately representable as values of the constant type. </p>
</blockquote>
<p>344 is a typed constant because of the <code>byte()</code>. <code>v</code> on the other hand is an integer, and 344 fits in an integer, so you just have the normal integer truncation when you convert it to a byte.</p>
<p>You might find <a href="https://blog.golang.org/constants" rel="nofollow">https://blog.golang.org/constants</a> and <a href="http://www.goinggo.net/2014/04/introduction-to-numeric-constants-in-go.html" rel="nofollow">http://www.goinggo.net/2014/04/introduction-to-numeric-constants-in-go.html</a> useful.</p></pre>3264128256: <pre><p>Thanks! </p>
<p><a href="https://golang.org/ref/spec#Conversions" rel="nofollow">https://golang.org/ref/spec#Conversions</a> actually cleared things up for me</p>
<p>Under, <em>Conversions between numeric types</em> for non constant numeric values</p>
<blockquote>
<ol>
<li>When converting between integer types, if the value is a signed integer, it is sign extended to implicit infinite precision; otherwise it is zero extended. It is then truncated to fit in the result type's size. For example, if v := uint16(0x10F0), then uint32(int8(v)) == 0xFFFFFFF0. The conversion always yields a valid value; there is no indication of overflow.</li>
</ol>
</blockquote></pre>barsonme: <pre><p>If you see here: <a href="https://play.golang.org/p/L5Zqnwh6O5" rel="nofollow">https://play.golang.org/p/L5Zqnwh6O5</a></p>
<p>It becomes a bit more obvious.</p>
<p><code>const b1</code> and the <code>344</code> literal are (untyped) constants, so the compiler knows their values before hand. Since in both cases you're essentially calling <code>byte(344)</code>, the compiler can see that <code>344 > ^byte(0)</code> and provides the "constant over flows ..." error. Note that this error happens on the lines where you call the conversion (i.e., 16 and 19) because the compiler inserts the literal values of the untyped constants and evaluates the expression as far as it can.</p>
<p><code>b2</code> and <code>b3</code> are inferred type variables, so their type is going to be the smallest integer that can hold the literal value. Because they're variables (not constants) the value may be changed at any time, so even though the compiler knows the values are initialized to 344, it cannot 100% determine that the future <code>byte(b2)</code> or <code>byte(b3)</code> conversion will cause an overflow.</p>
<p><code>b4</code> and <code>b5</code> are different because they're typed. That means the compiler can determine (at compile time) that the initialized value is too large for its type, thus causing an overflow. (It's why they overflow at line 11 and 13 not line 25 and 26.)</p></pre>sodoburaka: <pre><p>can someone pleaee ELI5 why/when would one use b4 := byte(344), and expect b4 to be 88 without compiler warning?</p>
<p>I dont tend to overuse byte type as other ppl I know, but I hear them complain about different-than-expected behaviour during string manipulation. </p></pre>bmurphy1976: <pre><p>You shouldn't. People who do this are bad people and shouldn't be allowed to write code. It may make sense now, but it sure as hell won't when somebody else is looking at it six months down the road. Don't do it!</p></pre>barsonme: <pre><p>If you do this you are a Bad Person.</p>
<p>Don't be a Bad Person.</p>
<p>Bad Persons don't pass code review.</p>
<p>We don't like Bad Persons.</p></pre>tinygopher: <pre><p>Just code the code.</p></pre>
