Last call for feedback on Go 1.13 language changes

837 views
Skip to first unread message

Robert Griesemer

unread,
Apr 24, 2019, 10:23:00 AM4/24/19
to golang-dev

Hello Gophers,


We are fast approaching our development freeze (starting beginning of May, 2019).


As you may remember, we introduced a new process for Go 2 related language changes in our blog post Go 2, here we come!. We started the process with Go 1.13 by tentatively accepting the following proposals at the beginning of the current dev cycle (beginning of February 2019):


1. Go 2 number literal changes

This comprises an overhaul of the valid notations for number literals. Specifically, binary integer literals (e.g., 0b1010); an alternative, more modern notation for octal numbers (e.g., 0o677); support for hexadecimal floating-point numbers (e.g., 0x1.2p-3); and finally the ability to use the underscore (‘_’) character to separate digits for improved readability (e.g., 0x_1234_5678). These proposals are discussed at:

2. Signed integer shift counts

This proposal permits the use of signed integers as shift counts and is expected to significantly reduce the need for (superficial) uint conversions. Discussion is at:



We have landed the necessary changes at tip in early February of this year. Per the blog post, we will make the final decision regarding the acceptance of these new language features shortly after the dev freeze, in early May.


(Our blog post also proposed adopting issue #20706 General Unicode identifiers based on Unicode TR31. This turned out to be more complicated than expected, and we dropped this proposal from the original list.)


This is a last call for feedback. Please submit any comments you may have on the respective issues in the issue tracker. Use the thumbs-up emoji to express general approval. Instead of a thumbs-down, please comment as to why you believe the respective feature should not be included.


Thanks for your feedback and all your help improving Go!

Robert Griesemer, for the Go Team


rajende...@saven.in

unread,
Apr 24, 2019, 10:48:08 AM4/24/19
to golang-dev
Is https://github.com/golang/go/issues/29934 also part of this process?


______________________________________________________________
Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. This message may not represent the opinion of Saven Technologies Ltd., and does not constitute a contract or guarantee. Any review, re-transmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.

Russ Cox

unread,
Apr 24, 2019, 11:33:05 AM4/24/19
to rajende...@saven.in, golang-dev
On Wed, Apr 24, 2019 at 10:48 AM rajender.reddy via golang-dev <golan...@googlegroups.com> wrote:
Is https://github.com/golang/go/issues/29934 also part of this process?

Yes, sorry for leaving that one out of the list.

Russ

Liam

unread,
Apr 27, 2019, 1:40:04 AM4/27/19
to golang-dev
From what I have seen, the Go 2 Error Values plan[1] has not received enough exposure to generate the level of feedback necessary to support a go/no-go decision re a major change -- one we cannot opt-out of, at that.

I suspect that the overwhelming majority of Go developers has no idea this is in the works. It was covered once on the blog last August in the Draft Design summary, when there wasn't any code behind it. It was not mentioned in Go 2 Here We Come[2], nor at the start of this thread. It wasn't mentioned on golang-dev until I posted a link to the issue tracker, but my posts would see a fraction of the attention vs those by Rob, Robert, Russ, Ian, et al.

There are outstanding issues with the current draft, specifically its performance[3] and API[4].

If it lands in 1.13, please give it Experimental status, with a build or env flag to disable changes to existing APIs, and perhaps a way to re-enable them on a per-function or per-package basis.

thepud...@gmail.com

unread,
Apr 27, 2019, 8:48:53 AM4/27/19
to golang-dev
Regarding Liam's comments on the Go 2 error values discussion, one concrete action could be to open a new thread on golang-nuts titled something like "Last call for feedback: Go 2 error values proposal".

Threads like that sometimes generate useful discussion, or sometimes just end quickly, but it seems it could be worthwhile to reach out more broadly than golang-dev for a final round of feedback.

In that post, ideally someone from the Go team who has been watching the discussion could include a short statement at least around what are the most significant changes since the initial design doc was posted.

However, time is short, so maybe someone from the broader community could open that discussion instead.

Given the number of other changes afoot in Go, I would tend to agree that the error values proposal has been masked a bit by other changes with bigger headlines (e.g., generics, modules).

As an example, I am glad type aliases are in the language. That said, even though I have more personal interest in the error values proposal than the type aliases proposal, I certainly followed the type aliases discussion much more closely than I followed the error values discussion because type aliases were not competing for as much oxygen at the time.

One thing that helped quite a bit with the type alias discussion and the modules discussion was a curated summary of the discussion so far, which made the discussion much easier to follow, especially for someone newly joining the discussion. (In other languages that don't do something similar, discussions frequently rapidly lose the signal to noise contest, with post after post along the lines of "I haven't had time to read all these other posts, but it seems obvious that...", or "I've stopped reading the discussion, but I wanted to repeat my point about..."). Ideally the curated summary would at least address:

* Significant changes since the original proposal
* Most common questions about the proposal
* Most common objections or changes suggested, and the current best response

I am not aware of a summary like that for the error values proposal. Of course, that takes time and energy, but perhaps a quick pass could still be of value (or if it exists already, then re-broadcasting its location could be useful).

Side note: it seems the "feel" of golang-nuts has become noticeable less friendly and welcoming over the course of the last 18 months or so. Part of that might be because change bring out stronger opinions in people. In any event, if someone does open a golang-nuts thread on this topic, perhaps it would be worthwhile to conclude the opening post with a "Let's remember our friendly gopher values and aim to keep this discussion polite", or something along those lines.

Regards,
thepudds

David Golden

unread,
Apr 27, 2019, 9:00:42 AM4/27/19
to thepud...@gmail.com, golang-dev
On Sat, Apr 27, 2019 at 8:48 AM <thepud...@gmail.com> wrote:
Threads like that sometimes generate useful discussion, or sometimes just end quickly, but it seems it could be worthwhile to reach out more broadly than golang-dev for a final round of feedback.


I'm a relative newcomer to this list (hi, all!), but I concur with Liam and thepudds.  Thinking about the Go 2018 survey results, they pointed to declines in leadership confidence, leadership understanding of needs, comfort approaching leadership with feedback, and feeling welcome in the community.  Two specific recommendations were reducing elitism and increasing transparency.

I think it would be wise to err on the side of seeking too much feedback rather than too little before making irreversible changes.

Regards,
David
Reply all
Reply to author
Forward
0 new messages