Thanks. I may have been imprecise using ``implementation specific''. I did not mean it in the C-like manner that the ``meaning'' of some (typed) value depends on the platform (length of some words) or the choice of the compiler writer for a given platform.
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). . Likewise I maintain that while internally consistent and meaninfull thereby, purely from the point of view from usage of English. a sentence from https://golang.org/blog/constants. like "an untyped constant has a default type" is confusing, especially for beginners: I would simply not call something which has a (default) type "untyped" (even if the mechanism justifying the distinction is useful). Again one can say, the compiler treats it as not having a final type yet, but when the time comes for decision, then a type will be chosen and then checked to be compatible with bool. All fine, but reads confusing for outsiders (the mechanism itself is clearer than the terminology), But I get the _idea_ behind the notion of being "untyped", which is the important part, thanks for the discussion. But it's a really a terminology question. I only can't imagine explaining it to students: ``remember, true is untyped, but it can only be used as if it had type bool''. On Wednesday, November 2, 2016 at 2:34:56 PM UTC+1, Ian Lance Taylor wrote: > > On Wed, Nov 2, 2016 at 4:27 AM, Martin Steffen <martin....@gmail.com > <javascript:>> wrote: > > > > So calling the use of "ok" an ``untyped boolean'' it seems a bit > > Go-specific (and/or go-implementation-centric) > > terminology. Indeed the section about "constants" (mentioned in an > earlier > > reply) sheds some light, in > > that it's a special case of how the Go specification speaks about typing > > issues surrounding literals. > > It's Go-specific, but in the context of Go it's meaningful. It's not > implementation-centric. Remember that in Go if you write > > type B1 bool > type B2 bool > var v1 B1 > var v2 B2 > > then it is a type error to write > > v1 = v2 > > So an untyped boolean, like an untyped int, etc., is a value that can > be assigned to any type whose underlying type is bool without > requiring a type conversion. > > It may help to read https://golang.org/blog/constants. > > Ian > -- 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.
