spec: language change review meeting minutes

[griesemer]

The Go 2 proposal review group meets monthly (every first Wednesday of a month) to review pending Go 2 proposal issues and move them along in the proposal process.

Review consists primarily of checking that discussion is ongoing, commenting on issues to move discussion along, summarizing long discussions, CC’ing experts, and accepting or closing proposals when the discussion on the GitHub issue has reached a clear consensus about the outcome.

Review also includes closing proposals that are untenable (for example, because the changes are sufficiently backwards-incompatible even after allowing for significant changes to the language as part of the Go 2 effort, or violate key design goals of the language or packages).

This meta-issue records minutes of the Go 2 proposal review meetings as issue comments, so that they can be cross-linked easily with the relevant issues. This meta-issue is for minutes only; comments that are not meeting minutes will be deleted.

(See also #33502 which records the minutes of non-Go 2 proposals review meetings).

[griesemer]

2019-08-27 / @bradfitz, @griesemer, @ianlancetaylor

• proposal: Go 2: add a ternary conditional operator #33171 add a ternary conditional operator
  • likely decline, final call for comments
• Proposal: Go2: local/private to file #33202 local/private to file
  • likely decline, final call for comments
• proposal: spec: add Posit data type #33205 add Posit data type
  • commented, put on hold
• spec: allow 'any' for 'interface{}' in non-constraint contexts #33232 add alias for interface {} as any
  • commented, put on hold
• proposal: add built-in function "formallyRead" for preventing elimination of "dead" stores #33325 add built-in function "formallyRead" for preventing elimination of "dead" stores
  • commented, closed (alternative solution exists)
• proposal: Go 2: negative slice/array indexes #33359 negative slice/array indexes
  • adjusted title
  • commented (no action taken)
• proposal: Go 2: add elixir-like pipe operator #33361 add elixir-like pipe operator
  • commented with solution using existing language
  • likely decline, final call for comments
• proposal: Go 2: simplify error handling with try err == nil {} except {} #33387 simplify error handling with try err == nil {} except {}
  • likely decline, final call for comments
• Proposal: Go 2: merge Type Assertion notation x.(T) into Explicit Conversion notation T(x) #33480 merge Type Assertion notation x.(T) into Explicit Conversion notation T(x)
  • likely decline, final call for comments
• proposal: Go 2: allow self-referencing closures #33167 allow self-referencing closures
  • commented (no action taken)

[griesemer]

2019-09-03 / @bradfitz, @griesemer, @ianlancetaylor

• proposal: Go 2: negative slice/array indexes #33359 Go 2: negative slice/array indexes
  • commented
• Proposal: Go 2: add chained interval comparisons #33694 Go 2: add chained interval comparisons
  • commented
• proposal: Go 2: Destructuring operator to assign fields in different types of the structs #33957 Go 2: Destructuring operator to assign fields in different types of the structs
  • commented
• io: clearly document when CopyBuffer does not use the buffer #32306 io: deprecate CopyBuffer
  • commented (request for feedback)
• proposal: Go 2: "onerr return" #32848 ** 32848**
  • commented
  • likely decline, final call for comments
• Proposal: Go2: try: Change try() proposal to use a special character in the position where an error is returned #32884 Go2: try: Change try() proposal to use a special character in the position where an error is returned
  • commented
  • likely decline, final call for comments
• Proposal: Go2: Tuple type #32941 Go2: Tuple type
  • commented
  • likely decline, final call for comments

[griesemer]

2019-09-10 / @bradfitz, @griesemer, @iant

• proposal: Go 2: negative slice/array indexes #33359 Go 2: negative slice/array indexes
  • discussed, waiting for more community feedback
• Proposal: Go 2: add chained interval comparisons #33694 Go 2: add chained interval comparisons
  • commented
  • likely decline, final call for comments
• proposal: Go 2: Destructuring operator to assign fields in different types of the structs #33957 Go 2: Destructuring operator to assign fields in different types of the structs
  • discussed, waiting for more community feedback
• proposal: Go 2: string interpolation #34174 string interpolation
  • commented

[griesemer]

20190-09-17 / @bradfitz, @griesemer, @iant

• io: clearly document when CopyBuffer does not use the buffer #32306 io: deprecate CopyBuffer
  • commented and declined (we’re not going to remove CopyBuffer)
  • changed to (non-Go 2) documentation issue
• proposal: Go 2: add tryfunc keyword to further reduce boilerplating for error handling #32964 add tryfunc keyword to further reduce boilerplating for error handling
  • commented
  • likely decline, final call for comments
• Proposal: go2 - Expand check functionality with scoped handle blocks #33002 Expand check functionality with scoped handle blocks
  • commented
  • likely decline, final call for comments
• proposal: Go 2: add "or err: statement" after function calls for error handling #33029 Go 2: add "or err: statement" after function calls for error handling
  • commented

[griesemer]

2019-09-24 / @bradfitz, @griesemer

• proposal: spec: allow conversion between return types and structs #33080 allow conversion between return types and structs
  • commented
• proposal: spec: disallow assigning >32bit untyped constant to variable of type int #20616 spec: disallow assigning >32bit untyped constant to variable of type int
  • discussed

[griesemer]

2019-10-01 / @bradfitz, @griesemer, @iant

• proposal: Go 2: "onerr return" #32848 Go 2: "onerr return"
  • closed (no further comments)
• Proposal: Go2: try: Change try() proposal to use a special character in the position where an error is returned #32884 Go2: try: Change try() proposal to use a special character in the position where an error is returned
  • closed (no further comments)
• Proposal: Go2: Tuple type #32941 Go2: Tuple type
  • commented
  • closed
• proposal: Go 2: add tryfunc keyword to further reduce boilerplating for error handling #32964 Go 2: add tryfunc keyword to further reduce boilerplating for error handling
  • likely decline, final call for comments
• proposal: Go 2: add a ternary conditional operator #33171 Go 2: add a ternary conditional operator
  • commented
  • closed
• Proposal: Go2: local/private to file #33202 Go2: local/private to file
  • commented
  • closed
• proposal: Go 2: add elixir-like pipe operator #33361 Go 2: add elixir-like pipe operator
  • commented
  • closed
• proposal: Go 2: simplify error handling with try err == nil {} except {} #33387 Go 2: simplify error handling with try err == nil {} except {}
  • closed
• Proposal: Go 2: merge Type Assertion notation x.(T) into Explicit Conversion notation T(x) #33480 Go 2: merge Type Assertion notation x.(T) into Explicit Conversion notation T(x)
  • closed
• proposal: Go 2: add "or err: statement" after function calls for error handling #33029 Go 2: add "or err: statement" after function calls for error handling
  • commented
  • likely decline, final call for comments
• proposal: Go 2: Make goroutine return channel with function result (promise) #33046 Go 2: Make goroutine return channel with function result (promise)
  • commented
• proposal: Go 2: remove the "if" keyword and use "err?!" to avoid error handling boilerplate #33067 Go 2: remove the "if" keyword and use "err?!" to avoid error handling boilerplate
  • commented
  • likely decline, final call for comments
• proposal: Go 2: list symbols that don't require package name #33070 Go 2: list symbols that don't require package name
  • commented
  • likely decline, final call for comments
• proposal: Go 2: Use ?<variable> simplify handling of multiple-return-values #33074 Go 2: Use ?<variable> simplify handling of multiple-return-values
  • commented
  • likely decline, final call for comments
• proposal: "Filled types": a mechanism to guarantee types are not nil at compile time #33078: "Filled types": a mechanism to guarantee types are not nil at compile time
  • commented

[griesemer]

2019-10-08 / @bradfitz, @griesemer, @iant

• Proposal: Go 2: add chained interval comparisons #33694: Go 2: add chained interval comparisons
  • closed (additional comments were unrelated)
• proposal: spec: allow conversion between return types and structs #33080: allow conversion between return types and structs
  • commented
• proposal: Go2: automatically take address of pointer parameters (reference arg behavior) #33088: Go2: automatically take address of pointer parameters (reference arg behavior)
  • commented
  • likely decline, final call for comments
• proposal: Go2: arg tags for marking const, other properties; use in vet #33122: Go2: arg tags for marking const, other properties; use in vet
  • closed (duplicate of proposal: Go 2: parameter tags for static analysis tools #24889)
• proposal: Go 2: use symbol or function call in assignment for error handling #33150: Go 2: use symbol or function call in assignment for error handling
  • commented
  • likely decline, final call for comments
• proposal: Go 2: simplify error handling with ? and ... #33152: Go 2: simplify error handling with ? and …
  • commented

[griesemer]

2019-10-15 / @bradfitz, @griesemer, @iant

• proposal: Go 2: add tryfunc keyword to further reduce boilerplating for error handling #32964 add tryfunc keyword to further reduce boilerplating for error handling
  • closed (no further comments)
• Proposal: go2 - Expand check functionality with scoped handle blocks #33002 Expand check functionality with scoped handle blocks
  • closed (no further comments)
• proposal: Go 2: mini-package: a solution to unify Go builtin and custom generics #32895 Go 2: mini-package: a solution to unify Go builtin and custom generics
  • likely decline, final call for comments
• proposal: spec: reduce noise in return statements that contain mostly zero values #21182 Go 2: reduce noise in return statements that contain mostly zero values
  • commented
• proposal: Go 2: Make goroutine return channel with function result (promise) #33046 Go 2: Make goroutine return channel with function result (promise)
  • likely decline, final call for comments
• proposal: "Filled types": a mechanism to guarantee types are not nil at compile time #33078 "Filled types": a mechanism to guarantee types are not nil at compile time
  • commented
  • likely decline, final call for comments
• proposal: Go 2: block scoped error handling #33161 Go 2: block scoped error handling
  • commented
  • likely decline, final call for comments
• proposal: Go 2: allow self-referencing closures #33167 Go 2: allow self-referencing closure
  • commented

[griesemer]

2019-10-22 / @bradfitz, @griesemer

• proposal: Go 2: integer comparison casting #35010 Go 2: integer comparison casting
  • commented
• proposal: Go 2: syntax for explicitly implementable interfaces #34996 Go 2: syntax for explicitly implementable interfaces
  • commented
• proposal: Go 2: looping with deferred condition as do while #34896 Go 2: looping with deferred condition as do while
  • commented
  • likely decline, final call for comments
• proposal: Go 2: extend "continue" to jump to start of function #34144 Go 2: extend "continue" to jump to start of function
  • commented
  • likely decline, final call for comments
• proposal: Go 2: allow trailing commas in the switch case enumerations #34088 Go 2: allow trailing commas in the switch case enumerations
  • commented
  • likely decline, final call for comments
• proposal: spec: extended type inference for make and new #34515 Go 2: extended type inference for make and new
  • commented

[griesemer]

2019-10-29 / @bradfitz, @griesemer, @iant

• proposal: Go 2: add "or err: statement" after function calls for error handling #33029 Go 2: add "or err: statement" after function calls for error handling
  • closed (no further comments)
• proposal: Go 2: Make goroutine return channel with function result (promise) #33046 Go 2: Make goroutine return channel with function result (promise)
  • closed (no further comments)
• proposal: Go 2: remove the "if" keyword and use "err?!" to avoid error handling boilerplate #33067 Go 2: remove the "if" keyword and use "err?!" to avoid error handling boilerplate
  • closed (no further comments)
• proposal: Go 2: list symbols that don't require package name #33070 Go 2: list symbols that don't require package name
  • closed (no further comments)
• proposal: Go 2: Use ?<variable> simplify handling of multiple-return-values #33074 Go 2: Use ?<variable> simplify handling of multiple-return-values
  • closed (by submitter on 2019-10-07)
• proposal: Go 2: allow self-referencing closures #33167 Go 2: allow self-referencing closures
  • commented
  • likely decline, final call for comments
• proposal: Go 2: negative slice/array indexes #33359 Go 2: negative slice/array indexes
  • commented
• proposal: Go 2: Type parameterized interface default methods #33818 Go 2: Type parameterized interface default methods
  • commented
• proposal: Go 2: Destructuring operator to assign fields in different types of the structs #33957 Go 2: Destructuring operator to assign fields in different types of the structs
  • commented
• proposal: Go 2: string interpolation #34174 string interpolation
  • commented
• proposal: Go 2: aggregate error handling & defer syntax sugar #34403 Go 2: aggregate error handling & defer syntax sugar
  • likely decline, final call for comments

[griesemer]

2019-11-05 / @bradfitz, @griesemer, @iant

• proposal: Go2: automatically take address of pointer parameters (reference arg behavior) #33088: Go2: automatically take address of pointer parameters (reference arg behavior)
  • closed (one comment, no substantial change)
• proposal: Go 2: use symbol or function call in assignment for error handling #33150: Go 2: use symbol or function call in assignment for error handling
  • closed (one comment, no substantial change)
• proposal: spec: extended type inference for make and new #34515 Go 2: extended type inference for make and new
  • commented
• proposal: spec: compile-time boolean assertions #34868 compile-time boolean assertions
  • commented
• proposal: Go 2: syntax for explicitly implementable interfaces #34996 Go 2: syntax for explicitly implementable interfaces
  • commented
  • likely decline, final call for comments
• proposal: Go 2: integer comparison casting #35010 Go 2: integer comparison casting
  • commented
  • likely decline, final call for comments

[griesemer]

2019-11-12 / @bradfitz, @griesemer

• proposal: Go 2: mini-package: a solution to unify Go builtin and custom generics #32895 Go 2: mini-package: a solution to unify Go builtin and custom generics
  • closed (no change in consensus)
• proposal: "Filled types": a mechanism to guarantee types are not nil at compile time #33078 "Filled types": a mechanism to guarantee types are not nil at compile time
  • closed (author ok’ed closing the issue)

Note: This was an abbreviated mtg due to external scheduling conflicts.

[griesemer]

2019-11-19 / @bradfitz, @griesemer, @iant

• proposal: Go 2: allow self-referencing closures #33167 Go 2: allow self-referencing closures
  • commented
  • removed final call for comments label due to valid feedback
• proposal: Go 2: looping with deferred condition as do while #34896 Go 2: looping with deferred condition as do while
  • closed (no further comments)
• proposal: Go 2: extend "continue" to jump to start of function #34144 Go 2: extend "continue" to jump to start of function
  • closed (no further comments)
• proposal: Go 2: allow trailing commas in the switch case enumerations #34088 Go 2: allow trailing commas in the switch case enumerations
  • closed (no change in concensus)
• Proposal: Go2: Error checking and handling inspired on Switch/Case statements #35086 Go2: Error checking and handling inspired on Switch/Case statements
  • commented
  • likely decline, final call for comments
• Proposal: Go2: Functions which when called, can cause the current function to return #35093 Go2: Functions which when called, can cause the current function to return
  • commented
• proposal: Go 2: add try statement to specify handler for unhandled errors #35179 Go 2: add try statement to specify handler for unhandled errors
  • commented
  • likely decline, final call for comments
• proposal: Go 2: Discard methods #35206 Go 2: Discard methods
  • commented
  • likely decline, final call for comments
• proposal: spec: anonymous struct literals #35304 anonymous struct literals
  • commented (in fair detail)
• Proposal: Go2: Vector Basic Type - Similar to []T but with enhancements #35307 Go2: Vector Basic Type - Similar to []T but with enhancements
  • commented

[ianlancetaylor]

2019-11-26 / @bradfitz, @ianlancetaylor

• proposal: Go 2: aggregate error handling & defer syntax sugar #34403 Go 2: aggregate error handling & defer syntax sugar
  • closed no change in consensus
• proposal: Go 2: Destructuring operator to assign fields in different types of the structs #33957 Go 2: Destructuring operator to assign fields in different types of the structs
  • likely decline, final call for comments
• proposal: Go 2: string interpolation #34174 Go 2: string interpolation
  • likely decline, final call for comments
• proposal: spec: extended type inference for make and new #34515 Go 2: extended type inference for make and new
  • commented
• proposal: spec: compile-time boolean assertions #34868 Go 2: compile-time boolean assertions
  • pinged author
• Proposal: Go2: Functions which when called, can cause the current function to return #35093 Go 2: functions which, when called, can cause the current function to return
  • pinged author
• proposal: spec: anonymous struct literals #35304 Go 2: anonymous struct literals
  • commented, pinged author
• Proposal: Go2: Vector Basic Type - Similar to []T but with enhancements #35307 Go 2: vector basic type
  • likely decline, final call for comments
• proposal: file scope #35387 Go 2: file scope
  • likely decline, final call for comments

[griesemer]

2019-12-03 / @bradfitz, @griesemer, @iant

• proposal: Go 2: syntax for explicitly implementable interfaces #34996 Go 2: syntax for explicitly implementable interfaces
  • closed (no change in consensus)
• proposal: Go 2: integer comparison casting #35010 Go 2: integer comparison casting
  • closed (no final comments)
• proposal: Go 2: block scoped error handling #33161 Go 2: block scoped error handling
  • closed (no final comments)
• proposal: compact syntax for multiple property assignation on a same object. #35528 compact syntax for multiple property assignation on a same object
  • likely decline, final call for comments
• proposal: treat declared function names as type names #35535 treat declared function names as type names
  • likely decline, final call for comments
• proposal: Go 2: change len, cap to return untyped ints if result is constant #31795 Go 2: change len, cap to return untyped ints if result is constant
  • closed (retracted by author)
• proposal: Go 2: don't allow taking address of slice elements #35654 Go 2: don't allow taking address of slice elements
  • likely decline, final call for comments

[griesemer]

2019-12-10 / @bradfitz, @griesemer, @iant

• proposal: Go 2: universal zero value with type inference #35966 Go 2: universal zero value with type inference
  • commented
• proposal: Go 2: allow self-referencing closures #33167 Go 2: allow self-referencing closures
  • likely decline, final call for comments
• proposal: Go 2: negative slice/array indexes #33359 Go 2: negative slice/array indexes
  • likely decline, final call for comments

[griesemer]

2019-12-17 / @griesemer

• Proposal: Go2: Error checking and handling inspired on Switch/Case statements #35086 Go2: Error checking and handling inspired on Switch/Case statements
  • closed (no final comments)
• proposal: Go 2: Discard methods #35206 Go 2: Discard methods
  • closed (no final comments)

Note: Due to other reviewers being ooo I only processed two proposals that were scheduled for closing.

[griesemer]

2020-01-07 / @bradfitz, @griesemer, @iant

• proposal: Go 2: Destructuring operator to assign fields in different types of the structs #33957 Go 2: Destructuring operator to assign fields in different types of the structs
  • closed (no change in concensus)
• Proposal: Go2: Functions which when called, can cause the current function to return #35093 Go 2: functions which, when called, can cause the current function to return
  • likely decline, final call for comments
• Proposal: Go2: Vector Basic Type - Similar to []T but with enhancements #35307 Go 2: vector basic type
  • closed (no change in concensus)
• proposal: file scope #35387 Go 2: file scope
  • closed (no change in concensus)
• proposal: compact syntax for multiple property assignation on a same object. #35528 compact syntax for multiple property assignation on a same object
  • closed (no change in concensus)
• proposal: treat declared function names as type names #35535 treat declared function names as type names
  • closed (no further comments)
• proposal: Go 2: don't allow taking address of slice elements #35654 Go 2: don't allow taking address of slice elements
  • closed (no further comments)
• proposal: Go 2: allow self-referencing closures #33167 Go 2: allow self-referencing closures
  • closed (no further comments)
• proposal: Go 2: negative slice/array indexes #33359 Go 2: negative slice/array indexes
  • closed (no change in concensus)
• proposal: Go 2: add try statement to specify handler for unhandled errors #35179 Go 2: add try statement to specify handler for unhandled errors
  • closed (no change in concensus)

[griesemer]

2020-01-14 / @bradfitz, @griesemer, @iant

• proposal: Go 2: run for loop in a goroutine with go keyword #36407 Go 2: run for loop in a goroutine with go keyword
  • commented
  • likely decline, final call for comments

We also discussed how we can make the Go 2 proposal review process more scalable. Currently it is fairly simple to create a new Go 2 proposal (like the proposal process intended), but then it becomes a significant burden for the proposal committee to ask and answer many of the questions that should have been answered by the proposal. We are planning to introduce a template of questions (CL 214820) with the intent to dismiss new proposals quickly if they don’t have reasonable answers for most of the questions.

[griesemer]

2020-01-21 / @bradfitz, @griesemer, @iant

• proposal: Go 2: remove map from keywords #36508 Go 2: remove map from keywords
  • commented
• proposal: Go 2: decorator support, like python decorator #36669 Go 2: decorator support, like python decorator
  • commented
• proposal: Go 2: make no result values expected when self has no return value too #36626 Go 2: make no result values expected when self has no return value too
  • commented
• proposal: spec: allow conversion between return types and structs #33080 allow conversion between return types and structs
  • commented
• Proposal: Go2: Drying up Error Handling in Go #36284 Go2: Drying up Error Handling in Go
  • commented

[griesemer]

2020-01-28 / @bradfitz, @griesemer, @iant

• proposal: Go 2: A compatible generics syntax #36457 Go 2: A compatible generics syntax
  • commented
  • closed (folded into proposal: spec: generic programming facilities #15292)
• proposal: make generic parentheses declaration order consistent with array bracket declaration order #36533 make generic parentheses declaration order consistent with array bracket declaration order
  • commented
  • closed (folded into proposal: spec: generic programming facilities #15292)
• proposal: Go 2: decorator support, like python decorator #36669 Go 2: decorator support, like python decorator
  • commented
  • likely decline, final call for comments
• proposal: spec: exhaustive switching for enum type-safety  #36387 Go 2: exhaustive switching for enum type-safety
  • commented
• proposal: Go 2: error handling with error receiver function #36338 Go 2: error handling with error receiver function
  • commented
• proposal: Go 2: obtain struct field name in type-safe way #36332 Go 2: obtain struct field name in type-safe way
  • commented
  • likely decline, final call for comments
• proposal: new builtin to pick from one of two values #36303 new builtin to pick from one of two values
  • commented
  • likely decline, final call for comments
• Proposal: make generic code clearer #36177 make generic code clearer
  • commented
  • closed (folded into proposal: spec: generic programming facilities #15292)

[griesemer]

2020-02-04 / @griesemer, @iant

• Proposal: Go2: Functions which when called, can cause the current function to return #35093 Go 2: functions which, when called, can cause the current function to return
  • closed (no further comments)
• container: add a comparable collection type #36702 proposal: Go needs a comparable collection type
  • commented
  • put on hold
• proposal: Go 2: expand power of range for slices/arrays #36816 proposal: Go 2: expand power of range for slices/arrays
  • commented
• proposal: Go 2: initialise funcs with custom type names #36855 Go 2: initialise funcs with custom type names
  • commented
  • likely decline, final call for comments
• proposal: Go 2: indentation in multiline raw string literals #36863 Go 2: indentation in multiline raw string literals
  • closed (duplicate of runtime: raising the number of GOMAXPROCS cause oom #32950)
• proposal: Go 2: explicit nil and pointer param #36884 Go 2: explicit nil and pointer param
  • commented
  • likely decline, final call for comments
• proposal: Go 2: permit converting a string constant to a byte array type #36890 Go 2: byte array <-> string conversions
  • commented
• proposal: Go 2: add nameof() built-in function #36924 Go 2: add nameof() built-in function
  • commented
• proposal: spec: exhaustive switching for enum type-safety  #36387 Go 2: exhaustive switching for enum type-safety
  • commented

[griesemer]

2020-02-18 / @bradfitz, @griesemer, @iant

• proposal: Go 2: improve error handling with “??” keyword for a special case #37243 Go 2: improve error handling with “??” keyword for a special case
  • likely decline, final call for comments
• proposal: Go 2: add ?? operator to select first non-zero value #37165 Add ?? operator to select first non-zero value
  • commented
  • on hold
• proposal: Go 2: remove map from keywords #36508 Go 2: remove map from keywords
  • likely decline, final call for comments
• proposal: Go 2: permit converting a string constant to a byte array type #36890 Go 2: permit converting a string constant to a byte array type
  • retitled
• proposal: Go 2: allow channel/map/type assertions in return (val, bool) #36955 Go 2: allow channel/map/type assertions in return (val, bool)
  • commented
  • likely decline, final call for comments
• proposal: Go 2: compiler chosen constants - make(const, <min>, <max>) #36972 Go 2: compiler chosen constants - make(const, , )
  • commented
• Proposal: Go 2: add C# like nameof() built-in function #37039 Go 2: add C# like nameof() built-in function
  • commented

[griesemer]

2020-02-25 / @bradfitz, @griesemer, @iant

• proposal: new builtin to pick from one of two values #36303 new builtin to pick from one of two values
  • closed (no change in consensus)
• proposal: Go 2: decorator support, like python decorator #36669 Go 2: decorator support, like python decorator
  • closed (no change in consensus)
• proposal: Go 2: obtain struct field name in type-safe way #36332 Go 2: obtain struct field name in type-safe way
  • closed (no change in consensus)
• Proposal: Go 2: add C# like nameof() built-in function #37039 Go 2: add C# like nameof() built-in function
  • commented
• proposal: Go 2: permit using errors.Return, etc., on LHS of an error assignment #37085 Go 2: permit using errors.Return, etc., on LHS of an error assignment
  • commented
• Proposal: Allow function to satisfy interface while returning interface superset #37129 Allow function to satisfy interface while returning interface superset
  • commented
  • likely decline, final call for comments
• proposal: spec: simplify error handling - error passing with "pass" #37141 Go 2: simplify error handling - error passing with "pass"
  • commented
• proposal: Go 2: time: deprecate time.Tick(d Duration) #37144 Go 2: time: deprecate time.Tick(d Duration)
  • closed (proposal withdrawn)
• strings: Title and ToTitle have similar names but do different things #37235 Title and ToTitle have similar names but do different things
  • commented
  • closed
• proposal: Go 2: implement an interface based on function signature if method name is ambiguous #37280 Go 2: implement an interface based on function signature if method name is ambiguous
  • commented
  • likely decline, final call for comments
• proposal: Go 2: integrated compile time language #37292 Go 2: integrated compile time language
  • commented
  • likely decline, final call for comments

[josharian]

I just wanted to let the proposal review group know that these meeting minutes are helpful, and that I appreciate you writing them up. If others feel the same way, please give a thumbs up to this comment, so that the review group knows. :)

[myitcv]

Unfortunately, @josharian, it will be a very quiet emoji party because the conversation is locked 🔒

[griesemer]

Dec 7, 2022 / @bradfitz, @griesemer, @iant

• proposal: Go 2: make short variable declaration re-declare already declared variables #55093
  • closed (no further comments)
• proposal: Go 2: add a feature to group the methods bound to a specific receiver. #55863
  • closed (no further comments)
• proposal: Go 2: Array or variadic destructuring to discrete variables #56094
  • closed (no further comments)
• proposal: Go 2: error handling with magic .handleErr() method #56126
  • closed (no further comments)
• proposal: Go 2: Heapless Go #56236
  • closed (no further comments)
• proposal: Go 2: Uniform Function Call Syntax #56242
  • closed (no change in concensus)
• proposal: Go 2: semi-constant conditionals #56256
  • closed (no change in concensus)
• proposal: Go 2: "trap" keyword for func-wise error handling #56258
  • closed (no change in concensus)
• proposal: Go 2: introduce a way of performing function chains #56283
  • closed (no change in concensus)
• proposal: allow packages to be aliased #56611
  • likely decline, final call for comments
• proposal: Go 2: just return the error  #56628
  • closed (duplicate of proposal: spec: reduce noise in return statements that contain mostly zero values #21182)
• proposal: Go 2: struct field methods, or anonymous callback helper types #56647
  • commented
• proposal: Go 2: returnFrom() #54361
  • likely decline, final call for comments
• proposal: spec: unions as sigma types #54685
  • commented
• proposal: Go 2: deriving code ala Haskell #54799
  • likely decline, final call for comments

[griesemer]

Jan 4, 2023 / @bradfitz, @griesemer, @iant

• proposal: allow packages to be aliased #56611
  • closed (no change in concensus)
• proposal: Go 2: returnFrom() #54361
  • closed (no further comments)
• proposal: Go 2: deriving code ala Haskell #54799
  • closed (no further comments)
• proposal: Go 2: error handling in one line #57547
  • likely decline, final call for comments
• proposal: handle error in minimal way #57552
  • likely decline, final call for comments
• proposal: spec: unions as sigma types #54685
  • commented
• proposal: Go 2: struct field methods, or anonymous callback helper types #56647
  • likely decline, final call for comments

[griesemer]

Feb 1, 2023 / @griesemer, @iant

• proposal: Go 2: error handling in one line #57547
  • closed (no change in concensus)
• proposal: handle error in minimal way #57552
  • closed (no change in concensus)
• proposal: Go 2: struct field methods, or anonymous callback helper types #56647
  • closed (no further comments)
• proposal: spec: add simple string interpolation similar to Swift #57616
  • likely decline, final call for comments
• proposal: Go 2: error handling by template functions #57822
  • likely decline, final call for comments
• proposal: Go 2: empty as an alias for struct{} #57825
  • likely decline, final call for comments
• proposal: Go 2: Shorter struct literals when key and variable name are the same #57949
  • likely decline, final call for comments
• proposal: Go 2: Add dimensionality to enrich type system and strengthen compile-type checking #57973
  • likely decline, final call for comments

[griesemer]

Mar 1, 2023 / @griesemer, @iant

• proposal: spec: add simple string interpolation similar to Swift #57616
  • closed
• proposal: Go 2: error handling by template functions #57822
  • closed (no further comments)
• proposal: Go 2: empty as an alias for struct{} #57825
  • closed (no change in concensus)
• proposal: Go 2: Shorter struct literals when key and variable name are the same #57949
  • closed
• proposal: Go 2: Add dimensionality to enrich type system and strengthen compile-type checking #57973
  • closed (no change in concensus)
• proposal: Go 2: string interpolation #34174
  • likely decline, final call for comments
• proposal: Go 2: string interpolation evaluating to string and list of expressions #50554
  • likely decline, final call for comments
• proposal: check - a minimal error handling improvement for readability #58520
  • likely decline, final call for comments
• proposal: Go 2: Add implicit single program multiple data #58610
  • likely decline, final call for comments

[griesemer]

Apr 12, 2023 / @griesemer, @iant

• proposal: Go 2: string interpolation #34174
  • closed (no further comments)
• proposal: Go 2: string interpolation evaluating to string and list of expressions #50554
  • closed (no further comments)
• proposal: check - a minimal error handling improvement for readability #58520
  • closed (no change in concensus)
• proposal: Go 2: Add implicit single program multiple data #58610
  • closed (no change in concensus)
• proposal: Go 2: Use an array as a ExpressionList for switch case statement #58868
  • likely decline, final call for comments
• proposal: Go 2: Function alias #58897
  • likely decline, final call for comments
• proposal: spec: Field expressions #59101
  • commented
• proposal: spec: shorthand for named return #59491
  • likely decline, final call for comments
• proposal: spec: add a mechanism to allow generic de- and re-structuring of complex values #45049
  • commented

[griesemer]

May 10, 2023 / @griesemer, @iant

• proposal: Go 2: Use an array as a ExpressionList for switch case statement #58868
  • closed (retracted)
• proposal: Go 2: Function alias #58897
  • closed (no further comments)
• proposal: spec: Field expressions #59101
  • likely decline, final call for comments
• proposal: spec: shorthand for named return #59491
  • closed (no change in consensus)
• proposal: Go 2: deferred code blocks #38520
  • likely decline, final call for comments
• proposal: spec: disallow impossible interface-interface type assertions #38907
  • put on hold

[griesemer]

Jun 7, 2023 / @bradfitz, @griesemer, @iant

• proposal: spec: Field expressions #59101
  • closed (no change in consensus)
• proposal: Go 2: deferred code blocks #38520
  • closed (no further comments)
• proposal: spec: expression to create pointer to simple types #45624
  • commented
• proposal: Go 2: function values as iterators #43557
  • closed (in favor of the discussion at user-defined iteration using range over func values #56413)

[griesemer]

Jul 19, 2023 / @griesemer, @iant

• proposal: spec: expression to create pointer to simple types #45624
  • commented
• proposal: Go 2: Error-Handling Paradigm #60720
  • likely decline, final call for comments
• proposal: Go 2: equality between an interface and nil should by default compare only by value (and not also type) #60786
  • likely decline, final call for comments
• proposal: spec: make byte array types ordered #61004
  • likely decline, final call for comments
• proposal: spec: allow overloading generic functions strictly on type constraints #61177
  • likely decline, final call for comments
• spec: create slices using constraints #61221
  • likely decline, final call for comments

[griesemer]

Aug 2, 2023 / @bradfitz, @griesemer, @iant

• proposal: Go 2: Error-Handling Paradigm #60720
  • closed (no change in consensus)
• proposal: Go 2: equality between an interface and nil should by default compare only by value (and not also type) #60786
  • closed (no change in consensus)
• proposal: spec: make byte array types ordered #61004
  • closed (no change in consensus)
• proposal: spec: allow overloading generic functions strictly on type constraints #61177
  • closed (no further comments)
• spec: create slices using constraints #61221
  • closed (retracted)
• proposal: Go 2: add built-in null for zero value of pointers #61489
  • likely decline, final call for comments

[griesemer]

Sep 6, 2023 / @bradfitz, @griesemer, @iant

• proposal: Go 2: add built-in null for zero value of pointers #61489
  • closed (no change in consensus)
• proposal: Go 2: orelse for streamlined error handling  #61750
  • likely decline, final call for comments
• proposal: Go 2: add tuple type #61920
  • likely decline, final call for comments
• proposal: Go 2: left side syntax for new variable #61933
  • closed (duplicate of proposal: spec: various changes to := #377)
• proposal: builtin/new: giving new the ability to call init when creating custom types #62240
  • likely decline, final call for comments
• proposal: Go2: error handling shortening #62378
  • likely decline, final call for comments
• proposal: Go 2: Single line if variant for returns and other jump statements #62434
  • likely decline, final call for comments

[griesemer]

Oct 4, 2023 / @bradfitz, @griesemer, @iant

• proposal: builtin/new: giving new the ability to call init when creating custom types #62240
  • closed (no change in consensus)
• proposal: Go2: error handling shortening #62378
  • closed (no change in consensus)
• proposal: Go 2: Single line if variant for returns and other jump statements #62434
  • closed (no change in consensus)
• proposal: Go 2: orelse for streamlined error handling  #61750
  • closed (no further comments)
• proposal: Go 2: add tuple type #61920
  • closed (no further comments)
• proposal: spec: memoization #62637
  • likely decline, final call for comments*
• proposal: spec: allow using spread on arrays in function calls, assignment and return statements #62685
  • likely decline, final call for comments*

[griesemer]

Nov 1, 2023 / @adonovan, @bradfitz, @findleyr, @griesemer

• proposal: spec: memoization #62637
  • closed (no change in consensus)
• proposal: spec: allow using spread on arrays in function calls, assignment and return statements #62685
  • closed (no change in consensus)
• proposal: Go 2: Index on any #63878
  • likely decline, final call for comments
• proposal: Go 2: Add Automatic Free Block #63671
  • likely decline, final call for comments
• proposal: Go 2: Error-Handling Paradigm with !err Grammar Sugar #63621
  • likely decline, final call for comments
• proposal: Go 2: abort? statement to bail early on non-nil errors #63575
  • likely decline, final call for comments
• proposal: Go 2: add sugar multiple keys to map to be tuples #63431
  • likely decline, final call for comments
• proposal: spec: Allow array receiver for methods #61752
  • likely decline, final call for comments

[griesemer]

Dec 6, 2023 / **@adonovan, @griesemer, @mdempsky **

• proposal: Go 2: Index on any #63878
  • retracted
• proposal: Go 2: Add Automatic Free Block #63671
  • closed (no change in consensus)
• proposal: Go 2: Error-Handling Paradigm with !err Grammar Sugar #63621
  • closed (no further comments)
• proposal: Go 2: abort? statement to bail early on non-nil errors #63575
  • closed (no change in consensus)
• proposal: Go 2: add sugar multiple keys to map to be tuples #63431
  • closed (no change in consensus)
• proposal: spec: Allow array receiver for methods #61752
  • closed (no change in consensus)
• proposal: Go 2: universal zero value with type inference #35966
  • likely decline, final call for comments
• proposal: Go 2: Add a new operator to pass error between calls. #64493
  • likely decline, final call for comments
• proposal: Go 2: call error handling functions with ... #64399
  • likely decline, final call for comments
• proposal: Go 2: generic overloaded constants #64333
  • likely decline, final call for comments
• proposal: Go 2: Error-Handling Paradigm with !err Grammar Sugar #64228
  • likely decline, final call for comments
• proposal: Go 2: '..' as alternative syntax for slicing #64118
  • likely decline, final call for comments
• proposal: spec: expression to create pointer to simple types #45624
  • commented

[griesemer]

Jan 10, 2024 / **@adonovan, @findleyr, @griesemer, @mdempsky **

• proposal: Go 2: universal zero value with type inference #35966
  • closed (no further comments)**
• proposal: Go 2: Add a new operator to pass error between calls. #64493
  • closed (no change in consensus)
• proposal: Go 2: call error handling functions with ... #64399
  • closed (no change in consensus)
• proposal: Go 2: generic overloaded constants #64333
  • closed (no further comments)**
• proposal: Go 2: Error-Handling Paradigm with !err Grammar Sugar #64228
  • closed (no change in consensus)
• proposal: Go 2: '..' as alternative syntax for slicing #64118
  • closed (no further comments)**
• proposal: spec: expression to create pointer to simple types #45624
  • commented
• proposal: Go 2: spec: switch case over range #64683
  • likely decline, final call for comments
• proposal: Go 2: variable length channel #64855
  • likely decline, final call for comments
• proposal: Go 2: use ? during variable assignment as implicit goto statement #64953
  • likely decline, final call for comments
• proposal: Go 2: type switch case statements with multiple interface types should produce an intersection of methods #65031
  • commented

[griesemer]

Feb 7, 2024 / @adonovan, @findleyr, @griesemer, @iant, @mdempsky

• proposal: Go 2: spec: switch case over range #64683
  • closed (no change in consensus)
• proposal: Go 2: variable length channel #64855
  • closed (no change in consensus)
• proposal: Go 2: use ? during variable assignment as implicit goto statement #64953
  • closed (no change in consensus)
• proposal: Go 2: type switch case statements with multiple interface types should produce an intersection of methods #65031
  • likely decline, final call for comments
• proposal: Go 2: component-wise operators for fixed size arrays #65216
  • likely decline, final call for comments
• proposal: Allow omitting types in callbacks if they can be inferred from the parameters #65369
  • closed (duplicate of proposal: spec: lightweight anonymous function syntax #21498)
• proposal: Go 2: Const generics #65555
  • commented
• proposal: spec: allow methods on generic structs which meet subset of type constraint #65394
  • commented (linked to proposal: spec: allow additional constraints on methods of generic types #64846)

[griesemer]

Mar 6, 2024 / @adonovan, @iant, @mdempsky

• proposal: Go 2: type switch case statements with multiple interface types should produce an intersection of methods #65031
  • closed (no change in consensus)
• proposal: Go 2: component-wise operators for fixed size arrays #65216
  • closed (no change in consensus)
• proposal: Go 2: Const generics #65555
  • likely decline, final call for comments
• proposal: spec: allow methods on generic structs which meet subset of type constraint #65394
  • commented
• proposal: Go 2: ? : for returning on function errors #65579
  • likely decline, final call for comments
• proposal: Go 2: allow importing the main function from a main package #65652
  • likely decline, final call for comments
• github: make language change proposal triage less confusing to the outside #65660
  • commented
• proposal: Go 2: allow else err after function calls #65793
  • likely decline, final call for comments
• proposal: spec: add builtin func 'is[T any](any) bool' #65846
  • removed v2 label
• proposal: Go 2: struct tag interpolation of constants #66108
  • likely decline, final call for comments
• proposal: Go 2: a type set with a single type should act more like that type #66123
  • likely decline, final call for comments

[griesemer]

Apr 3, 2024 / @adonovan, @bradfitz, @findleyr, @griesemer, @iant, @mdempsky

• proposal: Go 2: Const generics #65555
  • closed (no change in consensus)
• proposal: Go 2: ? : for returning on function errors #65579
  • closed (no further comments)
• proposal: Go 2: allow importing the main function from a main package #65652
  • closed (no further comments)
• proposal: Go 2: allow else err after function calls #65793
  • closed (no change in consensus)
• proposal: Go 2: struct tag interpolation of constants #66108
  • closed (no change in consensus)
• proposal: Go 2: a type set with a single type should act more like that type #66123
  • commented (removed "likely decline")
• proposal: Go 2: add trap on direct assignment with select block #66161
  • likely decline, final call for comments
• proposal: Go 2: currying functions with f{x} and f{arg: x} #66184
  • likely decline, final call for comments

[griesemer]

May 8, 2024 / @adonovan, @bradfitz, @griesemer, @iant

• proposal: Go 2: add trap on direct assignment with select block #66161
  • closed (no change in consensus)
• proposal: Go 2: currying functions with f{x} and f{arg: x} #66184
  • closed (no further comments)
• proposal: Go 2: a type set with a single type should act more like that type #66123
  • closed (treating as dup of spec: investigate if we can remove (most or all) needs for the concept of a core type #63940)
• proposal: spec: variadic type parameters #66651
  • closed (withdrawn by author)
• proposal: spec: generics: type initialization with value parameter #67064
  • commented
• proposal: Go 2: noncompare keyword to make structs non comparable #67196
  • likely decline, final call for comments
• proposal: Go2: error handling with #err suffix  #67251
  • commented
• github: make language change proposal triage less confusing to the outside #65660
  • commented

[griesemer]

Jun 5, 2024 / @adonovan, @bradfitz, @griesemer, @iant, @mdempsky

• proposal: spec: generics: type initialization with value parameter #67064
  • commented
• proposal: Go 2: noncompare keyword to make structs non comparable #67196
  • closed (no further comments)
• proposal: Go2: error handling with #err suffix  #67251
  • likely decline, final call for comments
• github: make language change proposal triage less confusing to the outside #65660
  • decided to adopt new process
• proposal: spec: handle errors with select #67316
  • likely decline, final call for comments
• proposal: spec: support user-defined variance (allow type parameters as type bounds) #67513
  • commented
• proposal: spec: support new form of switch statement during variable assignment which jumps to function-wide case blocks #65019
  • likely decline, final call for comments
• proposal: spec: cleaner error handling happy path via limited pattern matching #65266
  • commented

[ianlancetaylor]

For a few years now we've been running a proposal meeting known as the Go 2 proposal committee or the v2 committee. The original goal of the committee was to review proposed changes to the Go language and incompatible changes to the Go standard library. The minutes of the actions and decisions taken can be found in this issue.

Since the committee started Go has developed a standard way for handling incompatible Go library changes: a v2 release of the package. The recent Go 1.22 release introduced the first incompatible change to the standard library, by adding math/rand/v2 as a replacement for math/rand. (This is, of course, not really incompatible, as old programs continue to use math/rand and continue to work. Programs can update to the (slightly) incompatible math/rand/v2 at their leisure.)

This means that there is no longer a compelling reason to separate out incompatible library changes into a separate process. They can go through the regular proposal process instead. And, historically, almost all of the proposals reviewed by the v2 committee were in fact language change proposals (mostly for improvements to error handling).

Therefore, we are renaming the v2 committee to the language review committee, and going forward it will only handle language changes. Historically when the v2 committee sees a language change that seems worthy of broader attention, the proposal has been handed off to the regular proposal committee for final review. That will continue: the
role of the language review committee will be to do a first pass review of language change proposals, and pass the desirable ones on to the regular proposal committee.

As part of this I've shifted the issue labels in GitHub a bit. The existing v2 label is now being used only for incompatible library changes, to indicate that those changes, if accepted, will be in a v2 (or, perhaps far in the future, a v3) package. Those proposals will be reviewed by the regular proposal committee. The existing LanguageChange label continues to indicate a language change. Language changes being reviewed by the language review committee have a new label LanguageChangeReview. LanguageChange issues without the LanguageChangeReview label are expected to be reviewed by the regular proposal committee.

Going forward, when new language change proposals arrive, we will give them the LanguageChange and LanguageChangeReview labels. Historically these issues have been given a "Go 2:" prefix; they will now be given
a "spec:" prefix to indicate that they are changes to the language spec. Minutes will continue to appear in this issue.

We will as always continue to experiment and see what works best for the overall Go community.

After writing that, I want to remind people that almost all language change proposals are rejected. That is true for proposals that come from the broader Go community and also for proposals that come from the core Go team. Among the major goals of Go is stability. While we continue to improve and refine the language, adding experimental features is not a goal. We are willing to wait to solve problems until we have solutions that clearly work well. That said, we take all proposals seriously and review them as fairly as we can.

In particular, since the majority of language change proposals are related to error handling, I want to observe that we reliably reject these proposals. We agree that there is space to improve error handling. However, we have not yet seen a clearly good approach. Many error handling proposals are minor variations of existing proposals; by and large we've already considered these variations, and we simply aren't going to accept the new proposal even if it isn't quite the same as earlier ones. So while we welcome good proposals, please bear this in mind. Please also be aware of the meta issue #40432 and the long history of error handling proposals that can be seen at https://github.com/golang/go/issues?q=is%3Aissue++label%3Aerror-handling+ . While that is a lot to read and digest, we've read it all. Thanks.

[griesemer]

Aug 7, 2024 / @adonovan, @bradfitz, @findleyr, @griesemer, @iant

• proposal: Go2: error handling with #err suffix  #67251
  • closed (no change in consensus)
• proposal: spec: handle errors with select #67316
  • closed (no change in consensus)
• proposal: spec: support new form of switch statement during variable assignment which jumps to function-wide case blocks #65019
  • closed (no change in consensus)
• proposal: spec: catch error model, a rethink of check/handle #67859
  • likely decline, final call for comments
• proposal: spec: error handling with orbail err #67955
  • likely decline, final call for comments
• proposal: spec: error handling with || return err #68146
  • likely decline, final call for comments
• proposal: spec: allow import package name to be put after import path #68151
  • likely decline, final call for comments
• proposal: spec: check / handle with extra arguments #68720
  • likely decline, final call for comments
• proposal: spec: error handling with block statement #68745
  • likely decline, final call for comments
• proposal: spec: generics: type initialization with value parameter #67064
  • commented
• proposal: spec: float16 #67127
  • commented
• proposal: spec: support user-defined variance (allow type parameters as type bounds) #67513
  • commented

[griesemer]

Sep 4, 2024 / @adonovan, @findleyr, @griesemer, @iant

• proposal: spec: error handling with orbail err #67955
  • closed (no further comments)
• proposal: spec: error handling with || return err #68146
  • closed (no further comments)
• proposal: spec: allow import package name to be put after import path #68151
  • closed (no change in consensus)
• proposal: spec: check / handle with extra arguments #68720
  • closed (no further comments)
• proposal: spec: error handling with block statement #68745
  • closed (no change in consensus)
• proposal: spec: generics: type initialization with value parameter #67064
  • likely decline, final call for comments
• proposal: spec: float16 #67127
  • likely decline, final call for comments
• proposal: spec: support user-defined variance (allow type parameters as type bounds) #67513
  • likely decline, final call for comments
• spec: add "with" conditional branch #68968
  • likely decline, final call for comments
• proposal: spec: new builtin: handle #69045
  • commented

[griesemer]

Oct 2, 2024 / @adonovan, @bradfitz, @findleyr, @griesemer, @iant

• proposal: spec: generics: type initialization with value parameter #67064
  • closed (no change in consensus)
• proposal: spec: float16 #67127
  • closed (no change in consensus)
• proposal: spec: support user-defined variance (allow type parameters as type bounds) #67513
  • closed (no change in consensus)
• spec: add "with" conditional branch #68968
  • closed (no change in consensus)
• proposal: spec: catch error model, a rethink of check/handle #67859
  • closed (no change in consensus)
• proposal: spec: new builtin: handle #69045
  • likely decline, final call for comments
• proposal: spec: support goroutine local variables #69478
  • likely decline, final call for comments
• proposal: spec: add nothing type for functions that don't return #69591
  • likely decline, final call for comments
• proposal: spec: Values assigned to multi-case branches in type switches should have generics-style  #69705
  • commented and put on hold
• proposal: spec: error handling via iterator-inspired handler functions #69734
  • commented

[findleyr]

Nov 6, 2024 / @adonovan, @findleyr, @ianlancetaylor

• proposal: spec: new builtin: handle #69045
  • closed (no change in consensus)
• proposal: spec: support goroutine local variables #69478
  • closed (no change in consensus)
• proposal: spec: add nothing type for functions that don't return #69591
  • closed (no change in consensus)
• proposal: spec: error handling via iterator-inspired handler functions #69734
  • likely decline, final call for comments
• proposal: spec: conditional return with "return if"  #70147
  • likely decline, final call for comments
• proposal: spec: conditional return with return ?err? #70170
  • likely decline, final call for comments
• proposal: spec: change int to be arbitrary precision #19623
  • likely decline, final call for comments
• proposal: spec: add integer types with explicit overflow behavior, and remove unchecked operations on built-in integers #30209
  • likely decline, final call for comments

[griesemer]

Dec 4, 2024 / @adonovan, @bradfitz, @findleyr, @griesemer, @iant

• proposal: spec: error handling via iterator-inspired handler functions #69734
  • closed (no change in consensus)
• proposal: spec: conditional return with "return if"  #70147
  • closed (no further comments)
• proposal: spec: conditional return with return ?err? #70170
  • closed (no further comments)
• proposal: spec: change int to be arbitrary precision #19623
  • likely decline, final call for comments (commented)
• proposal: spec: add integer types with explicit overflow behavior, and remove unchecked operations on built-in integers #30209
  • closed (no further comments)
• proposal: spec: add structfield type and syntax to directly access a structs structfield #70564
  • likely decline, final call for comments
• proposal: spec: generics: type switch on parametric types #45380
  • moving back to regular proposal queue