proposal: Go 2:

[himanshu-patel-dev]

Author background

• Would you consider yourself a novice, intermediate, or experienced Go programmer?
  Intermediate
• What other languages do you have experience with?
  Python, Ruby

Related proposals

• Has this idea, or one like it, been proposed before?
  Not exactly, but there is one (a heap backed by a slice) Here. But above proposal is on hold and dosen't server the purpose of removing boiler plate code completely and get a data type for integer Heap. Which I am proposing in current proposal.
• Does this affect error handling?
  No, it dosen't affect error handleing.
• Is this about generics?
  No

Proposal

• What is the proposed change?
  Implementing a integer based heap and implementing all the interface functions, can be reduced for integers. We can provide a integer heap, like it is given in a actual package help doc container/heap. programmer can use this as data type to create new integer heap without having to implement all the function of heap interface. Code in the end of this proposal is an example how this data type will look. This makes creating and using int heap a lot faster (in implementation).
• Who does this proposal help, and why?
  This is inspired from sort.Ints and sort.Strings where altough we can implement an interface and make a sorting implementation for int slice and string slice but making it availalbe for basic data types like int float string etc saves boilerplate code and help programmer write code without frustration of implementing interface for basic data types like int.
• Please describe as precisely as possible the change to the language.
  The changes to language is minimal. Adding one concrete implementation of int heap with all necessary function/interface already implemented. To understand better look at the code in the end of this proposal.
• What would change in the language spec?
  Change will happen to spec of container/heap package. Changelog informing about a new way to init integer heap.
• Please also describe the change informally, as in a class teaching Go.
  Dear students, no more implementing of Less Swap Push Pop for simple heap use. Just initialize your variable like var h IntHeap and you get the functionality as you would get earlier after implementing all the functions yourself.
• Is this change backward compatible?
  Yes
• Orthogonality: how does this change interact or overlap with existing features?
  It overlaps in a way, where it allows progammer to use interface and implement heap for his/her favourite data type, while still leaving room for programmer who don't want to implement a fairly advanced data structure every time. Same think as in sort.Ints and sort.Floats.
• Is the goal of this change a performance improvement?
  No, performance is not the goal here.

Costs

• Would this change make Go easier or harder to learn, and why?
  Easier, abstract out the interface implementation if you don't really want to know.
• What is the cost of this proposal? (Every language change has a cost).
  Don't know, but can figure out if someone points to right resources.
• How many tools (such as vet, gopls, gofmt, goimports, etc.) would be affected?
  Don't know, but can figure out if someone points to right resources.
• What is the compile time cost?
  Don't know, but can figure out if someone points to right resources.
• What is the run time cost?
  Don't know, but can figure out if someone points to right resources.
• Can you describe a possible implementation?

package heap

type IntHeap []int

func (h *IntHeap) Len() int { return len(*h) }
func (h *IntHeap) Less(i, j int) bool {
	return (*h)[i] < (*h)[j]
}
func (h *IntHeap) Swap(i, j int) {
	(*h)[i], (*h)[j] = (*h)[j], (*h)[i]
}

func (h *IntHeap) Push(x any) {
	*h = append(*h, x.(int))
}

func (h *IntHeap) Pop() any {
	n := h.Len()
	lastEle := (*h)[n-1]
	*h = (*h)[0 : n-1]
	return lastEle
}

// ----------------- quick use case ----------------- 

func main() {
	h := &IntHeap{2, 1, 5}
	heap.Init(h)
	heap.Push(h, 3)
	fmt.Println(heap.Pop(h))
}

[seankhliao]

At this point in time, we're not considering changes to the container packages until we have a way forward with iterators.