On Wednesday, 2 November 2016 11:24:38 UTC-4, Martin Steffen wrote: > > I meant more: the _terminology_ of being untyped may reflect an internal > treatment of how the go compiler treats > those things: inside the go-compiler, the ``static phase''/type > checker/type inferencer may treat > for instance literals as being in one of > two states: one which is called "untyped", where said flexibility (or > polymorphism if you wish) is possible, and one where this > is not immediatly possible (without conversion). These to states are > called "untyped" and "typed" in the compiler. In that way, I meant > "implementation specific". > > Fair enough. I also understand why this flexibility in typing is very > desirable, useful etc. > > The only thing I maintain is that, if one would ask me (not that it's > generally recommended), > I'd had not chosen to call the phenomenon of this form of flexible or > polymorphiic handling > of literals in a typed language as "untypedness" > (even if that's accepted terminology in the Go community). > > For me (with my background), I would have called 5 to be "polymorphically > typed" in that it can carry more > than one type (namely as you said, all types which are ``compatible'' with > int without conversion). >
Yes, the terminology is confusing to someone with a background in type theory, but I have learned it's best not to swim against the current. A constant expression with an "untyped" type certainly has a type, one subject to a number of implicit conversions. Perhaps a better term would be "unnamed' or "uncommitted". An untyped integer can be assigned or converted to any named integer type such as int, uint16, or MyInt, at which point the value is committed to a particular representation. -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
