Skip to content

Instantly share code, notes, and snippets.

View JavierZunzunegui's full-sized avatar

Javier Zunzunegui JavierZunzunegui

  • Google
  • Munich
View GitHub Profile
@JavierZunzunegui
JavierZunzunegui / go2relaxedtypeconversionproposal.md
Last active February 4, 2020 13:15
go2 Relaxed Type Conversion Proposal

Relaxed Type Conversion Proposal

Motivation

While this is a standalone proposal, it is motivated by the go2 generics proposal (issue and doc). The connection between this proposal and generics is presented here (originally here).

Overview

In go, one can convert any type to another with the same type definition: type A int; var _ = A(int(1)) is perfectly valid (play).

@JavierZunzunegui
JavierZunzunegui / go2-readonly-and-immutability.md
Last active January 25, 2019 21:44
proposal: Go2: read-only and immutability

proposal: Go2: read-only and immutability

original github issue and discussion

Abstract

This document presents a solution on how to introduce read only and immutability support in go2. It is split into two parts:

  • A read-only language change that provides the expected compile-time guarantees with limited additional complexity or inconvenience to developers.
  • How immutability may be implemented on top of these language change, transparently to developers.
@JavierZunzunegui
JavierZunzunegui / go2genericscompilefeedback.md
Last active August 30, 2018 17:00
Go2 Generics Compile Feedback

Compile-time Feedback to Generics in Go 2 Draft Designs

Golang compiles fast, and this is an important feature when it is compared to other languages. The draft design makes a small reference to compile time performance implementation and efficiency but I believe this has to be clarified further.

Let me address the quote "In other words, this design permits people to stop choosing slow programmers, and permits the implementation to decide between slow compilers (compile each set of type arguments separately) or slow execution times (use method calls for each operation on a value of a type argument)". "Slow programmers" is the current 'do it your own way approach', which is largely agreed is not good enough. But "slow execution times", also referred to as