On Wed, Jan 29, 2020 at 12:57 PM Nigel Tao <nigel...@golang.org> wrote:
> For example, the https://golang.org/pkg/io/#LimitedReader struct just > exports its fields, and you use it like this > (https://go.googlesource.com/go/+/refs/heads/master/src/io/io_test.go#39). > There is no io.NewLimitedReader function. > Nit: It's not called that way, but there is <https://golang.org/pkg/io/#LimitReader>. > > > > True iterators are felt by their absence and would be easy to add. > > If you really want lazy lists, I'd use a generating function (a > closure) instead of slices. It seems to me that that's what you > discuss in your "Iterator variant A" example, so I'm not exactly sure > what you're asking for? New rules for the built-in "range" keyword?? > But iteration can already be: > > ``` > it := foobar.iterator() > for x := it(); x != nil; x = it() { > etc(x) > } > ``` > > which doesn't seem so onerous to require changing the language. To map > a function f isn't as terse as a Python list comprehension, but it's > still easy: > > ``` > it := foobar.iterator() > for x := it(); x != nil; x = it() { > fx = f(x) > etc(fx) > } > ``` > > > > A technical writer with an outside-in view of the language should be > hired on to do an edit pass and reorganization of the documents. > > Out of curiosity, have you looked at "The Go Programming Language" > book by Donovan and Kernighan? It's the same K as in K&R's "The C > Programming Language", which is generally regarded as excellent > language documentation. > > On a related point: > > > I got substantial help understanding interfaces from an old blog post by > Ian Lance Taylor > > If it's https://research.swtch.com/interfaces then the blog post > author is Russ Cox, not Ian Lance Taylor. > > > > Lookbehinds should be added to the regexp library. > > See https://groups.google.com/d/msg/golang-nuts/7qgSDWPIh_E/OHTAm4wRZL0J > > > Other thoughts below... > > ---- > > The idiomatic form of > ``` > switch child.(type) { > case *Commit: > successorBranches.Add(child.(Commit).branch) > } > ``` > is: > ``` > // Yes, the inner 'child' deliberately shadows the outer 'child'. > switch child := child.(type) { > case *Commit: > // Here, 'child' has the concrete type, not the interface type. > successorBranches.Add(child.branch) > } > ``` > > ---- > > ``` > func pipeline(source T) error { > { > result1, err1 := transform1(source) > if err1 != nil { > return err > } > > result2, err2 := transform2(result1) > if err2 != nil { > return err > } > > result3, err3 := transform3(result2) > if err3 != nil { > return err > } > > return nil > } > ``` > > Is indeed "eyeball friction". That's the motivation for > https://github.com/golang/proposal/blob/master/design/32437-try-builtin.md > , > which would make it: > > ``` > func pipeline(source T) error { > { > result1 := try transform1(source) > result2 := try transform2(result1) > result3 := try transform3(result2) > return nil > } > ``` > > For much, much more discussion (too much) see > https://github.com/golang/go/issues/32437 > > -- > 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/CAOeFMNUyWOXpFo6w8DL%3D7WMNGjXAvCc-rd8uSH8DXPyy9cY5zg%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/CAEkBMfFNAxNOfCHJ4FrPb_hzMjebjLkn%3Dzq8YrZbSZ2osrtm9Q%40mail.gmail.com.
