naah, thanks, that's ok.
As soon as I can acquire my own turing machine, I'll insist on 1 number type.
Until then I can live with different number types and some rules for
my finite machines.
On 5/21/19, Michael Jones wrote:
> Oh, Sorry. Have been away from email today. (Focused 100% in VS-code
Oh, Sorry. Have been away from email today. (Focused 100% in VS-code on a
cool feature for Go)
My statement was meant to convey an insight into a subtle aspect of Go's
constants and high-precision expression evaluation--that the "type" of
untyped constants/values, in the conversion rules sense,
Could you please clarify which statement your example is meant to
confirm or refute?
On 5/20/19, Michael Jones wrote:
> ahem...
> https://play.golang.org/p/7gcb9Yv7c9e
>
> On Mon, May 20, 2019 at 2:45 AM wrote:
>
>> https://golang.org/ref/spec#Constants
>>
>> "A constant may be given a type
ahem...
https://play.golang.org/p/7gcb9Yv7c9e
On Mon, May 20, 2019 at 2:45 AM wrote:
> https://golang.org/ref/spec#Constants
>
> "A constant may be given a type explicitly by a constant declaration
> or conversion, or implicitly when used in a variable declaration or an
> assignment or as an
https://golang.org/ref/spec#Constants
"A constant may be given a type explicitly by a constant declaration
or conversion, or implicitly when used in a variable declaration or an
assignment or as an operand in an expression. It is an error if the
constant value cannot be represented as a value of
On Mon, May 20, 2019 at 11:33 AM wrote:
>
> Hi,
> does this should work ?
The error is correct. See https://golang.org/ref/spec#Conversions
A constant value x can be converted to type T if x is representable by
a value of T.
An integer cannot represent the value 6.6 hence the
