I wouldn’t have don’t it that way. I would have made := mean all variables must be new. And = mean any new variable requires a decoration.
So in this case, var x,err = means x is new and err is reused. The variable clauses are segregated by a , > On Apr 23, 2023, at 9:07 AM, Axel Wagner <axel.wagner...@googlemail.com> > wrote: > > > > On Sun, Apr 23, 2023 at 4:01 PM Robert Engels <reng...@ix.netcom.com> wrote: >> Personally that syntax has always bothered me with readability. It requires >> lots of previous knowledge in some cases. A syntax like >> >> x, var y int = blah >> >> Is more explicit that x is reused and y is declared. > > That specific suggestion would not work. It would mean it is ambiguous > whether `var x, err = fmt.Println()` is mean to be a declaration of only x, > or both - and note that this specific order is the more relevant, as `err` is > the specific variable that tends to be re-used by `:=`. > There probably could be alternatives though. But that seems a moot point now. > > >> >> Go is all about being explicit until it isn’t. >> >> >> >>> On Apr 23, 2023, at 8:28 AM, 'Axel Wagner' via golang-nuts >>> <golang-nuts@googlegroups.com> wrote: >>> >>> Just to nit-pick everyone: Short variable declarations are not there to >>> omit type information. You can do that with a regular variable declaration: >>> https://go.dev/play/p/6XePFCh-6G2 >>> Short variable declarations exist to 1. be shorter and 2. allow you to >>> avoid re-declaration errors when assigning multiple variables: >>> https://go.dev/play/p/bgbU9mTunhL >>> So, IMO short variable declarations definitely increase readability, just >>> by that latter effect. Type-inference is a bonus. >>> >>> On Sun, Apr 23, 2023 at 3:09 PM Jesper Louis Andersen >>> <jesper.louis.ander...@gmail.com> wrote: >>>> On Sun, Apr 23, 2023 at 12:31 AM jlfo...@berkeley.edu >>>> <jlforr...@berkeley.edu> wrote: >>>>> >>>>> Short definitions detract from one of Go’s primary goals - readability. I >>>>> started using Go in the first place because I wanted a strongly typed >>>>> language with explicit type declarations. >>>> >>>> Your claim of readability is not held by everyone. Some people prefer >>>> there be no type information in a program because the type information >>>> "detracts from what the program is doing". Hence, it becomes rather hard >>>> to please everybody. >>>> >>>> Short variable declarations are a poor man's type inference. In fully >>>> type-inferred languages, you can omit types everywhere, and the compiler >>>> will deduce an appropriate type for each declaration. It will typically >>>> pick the most general type for an expression. The type information is >>>> still there, but it is generated on-demand by the compiler, and programs >>>> which fail the type check are rejected. Haskell and OCaml are good >>>> examples of programming languages following this style. Yet in both >>>> languages, you often see type declarations sprinkled throughout the code >>>> base to guide the reader. You sort-of assume a certain amount of >>>> experience, and add types as you see fit to capture that experience. >>>> Often, you end up with your interfaces being type-annotated, but your >>>> internal code avoiding annotation. >>>> >>>> The grand advantage of type inference is that the types can vary easily. >>>> If you change a fundamental type, the compiler will check that your change >>>> is sound. And you don't have to go around the code base and change every >>>> occurrence. That's a really nice boon. >>>> >>>> We are slowly moving into a world where the compiler and the programmer >>>> are working on the code at the same time. You ask the compiler to fill out >>>> gaps in the programs you are writing. The result is that your editor can >>>> live-annotate the appropriate types of declarations and expressions >>>> because it can be lifted from the compiler. When I write OCaml, for >>>> instance, my editor annotates functions with types for me by adding a line >>>> above the function declaration in a smaller font. These lines only occur >>>> virtually in the buffer, and aren't present in the program file. >>>> >>>> For some languages, such as Agda, the interaction is even stronger: you >>>> can ask the compiler to fill in parts of the program based on the types >>>> they have. That is, types and terms coalesce and there is no >>>> stratification between them. Writing a term makes the compiler deduce the >>>> type. Writing a type makes the compiler deduce and fill in the term. >>>> Coming strong into this are large language models from machine learning. >>>> You can fill in lots of gaps in programs via LLMs. Programming often >>>> contains a lot of janitorial tasks around a computational kernel and LLMs >>>> can accelerate the janitor. In the future, I hope someone takes an LLM and >>>> starts exploiting type information. I have a hunch it's going to be far >>>> more effective for languages which have static type systems (inferred or >>>> not) because there's a much richer set of information you can exploit. >>>> >>>> >>>> >>>> -- >>>> J. >>>> -- >>>> 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. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/golang-nuts/CAGrdgiVd3BMOKE6ohRbwTmC_AhSY3Zht4LxK%3DFQjqj_YocoZAg%40mail.gmail.com. >>> >>> -- >>> 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. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/golang-nuts/CAEkBMfFtaM2KMPxRYdaFS79O0vf91RPzQBHwHa2CLJWB6r5DJQ%40mail.gmail.com. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/F41DE935-9CF0-4E4E-81C1-010476DF264A%40ix.netcom.com.
