Yes, I should perhaps have prefaced my previous post by saying it depends what you mean by 'type inference' :)
Rightly or wrongly, I think of it as either inferring the type of a variable or constant from its initialization expression or, in the case of a constant, inferring that it is an untyped constant of a certain kind - boolean, rune, integer, floating-point, complex or string. There is, of course, no* explicit* way to specify that a constant is of an untyped kind in any case. However, if you take the stricter view that type inference can only apply to typed constants, then I'd agree with you that (a) doesn't use type inference. Alan On Monday, February 4, 2019 at 6:17:05 PM UTC, 伊藤和也 wrote: > > I agree that (b), (c), (d) use type inference but not (a) because in (a), > both "num1" and "100" are untyped constants so they don't have types so > there is no need to use type inference. > > (a) const num1 = 100 > (b) var num2 = num1 > > (c) const num1 = int(100) > (d) num2 := num1 > > However, if type inference is used to infer that "num1" is untyped from > untyped "100", I agree that (a) also uses type inference. > (a) const num1 = 100 > 2019年2月4日月曜日 2時43分45秒 UTC+9 伊藤和也: >> >> In all the constant and variable declarations below, is type inference >> used? If not, which declarations use type inference? >> (a) const num1 = 100 >> (b) var num2 = num1 >> >> (c) const num1 = int(100) >> (d) num2 := num1 >> > -- 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.
