Re: [go-nuts] Re: new range over int docs?

lt;<<<<<<< 2024, no? > > On Wed, Feb 7, 2024 at 5:24 PM Robert Griesemer wrote: > >> Spec is up-to-date at tip, now: https://tip.golang.org/ref/spec >> https://golang.org/ref/spec should be updated soon, too. >> Apologies for the confusion. >> - gri

Re: [go-nuts] Re: new range over int docs?

Spec is up-to-date at tip, now: https://tip.golang.org/ref/spec https://golang.org/ref/spec should be updated soon, too. Apologies for the confusion. - gri On Wed, Feb 7, 2024 at 8:11 AM Jason E. Aten wrote: > Thanks Peter. I see the latest spec at tip.golang.org. > > p.s. Go Team: At least in

Re: [go-nuts] Any interest in nat.mulRange simplification/optimization?

The overflow fix is pending: CL 554617 I filed https://github.com/golang/go/issues/65027 for a possibly faster mulRange implementation. - gri On Mon, Jan 8, 2024 at 11:47 AM Robert Griesemer wrote: > Hello John; > > Thanks for your interest in this code. > > In a (long past) im

Re: [go-nuts] Any interest in nat.mulRange simplification/optimization?

Hello John; Thanks for your interest in this code. In a (long past) implementation of the factorial function, I noticed that computing a * (a+1) * (a+2) * ... (b-1) * b was much faster when computed in a recursive fashion than when computed iteratively: the reason (I believed) was that the iterat

Re: [go-nuts] Re: An mistake in tip spec?

Indeed. There's no shortcuts possible here. Hopefully this works better (and closely matches the implementation): https://go-review.googlesource.com/c/go/+/376834 - gri On Thu, Jan 6, 2022 at 10:08 PM Axel Wagner wrote: > On Fri, Jan 7, 2022 at 2:35 AM 'gri' via golang-nuts < > golang-nuts@googl

[go-nuts] Generics and parentheses

We have received a variety of feedback on the generics draft design (blog ). Thanks to everyone who took the time to read it, play with generics code in the playground

[go-nuts] Go Blog: Next steps toward Go 2

For those of you who are not actively following the Go Blog , yesterday we have posted a new entry on proposals we are considering for Go 1.14: https://blog.golang.org/go2-next-steps - gri -- You received this message because you are subscribed to the Google Groups "g

Re: [go-nuts] Cyclic types

extra cost? Or are these cases esoteric and don't show up in real code? And if we use simpler algorithms, is there an easy way to describe which types are accepted and which aren't? On Wed, May 9, 2018 at 10:00 AM Robert Griesemer wrote: > This sounds all good. > > I am not disp

Re: [go-nuts] Cyclic types

, I agree that there shouldn't be a difference between cycle detection by a human and a computer. But the problem is that the computer may be using an algorithm that may be conservative, or incorrect, or not very general (for the sake of speed in the common case). On Wed, May 9, 2018 at 1:21 AM Jan

Re: [go-nuts] Question regarding compiler internals

Hi Jacob; As you have probably figured out yourself by now, coming up with some syntax for parametrized types (and perhaps even a set of formalized rules) is the easy part of a complete implementation. If you have been working on the existing compiler, you must have adjusted the cmd/compile/inter

Re: [go-nuts] Are short variable declarations necessary?

To answer the subject line question: No, short variable declarations are not technically necessary. We could have chosen not to have them. But there are good reasons for them. It was a deliberate design decision. Let me throw in a bit of historical perspective: Rob's invention of ":=" in one of h