| //A generics proposal for Go, introducing one new type (generic) and one new builtin function (typeof), no syntax changes. | |
| //Function add takes arguments of any type. | |
| //The return value is automatically inferred based on the arguments, can be inlined by the compiler. | |
| //Both arguments must be the same type and addable or else a compiler error will be raised. | |
| //It's the developer's responsibility to document which types can be passed to this function. | |
| func add(a, b generic) generic { | |
| return a+b | |
| } |
There are two main parts to the Contracts Draft Design:
Type Parameters are mostly independent of Contracts; Contracts builds on Type Parameters. The two concepts are well thought-out and many corner cases have been looked at.
These are some specific points that I think are done well by the current generics draft proposal, not in any particular order:
This document references the Contracts Draft Design for Go Generics, dated 31 July 2019.
The current design uses parentheses to delimit type parameter clauses, but this makes the code difficult to read. This is covered briefly in Non-Parenthetical Delimiters from the essay Towards Clarity: Syntax Changes for Contracts in Go, as well as in many other points of feedback which can be found at https://github.com/golang/go/wiki/Go2GenericsFeedback as linked documents or inline comments.
The official draft states:
Why not use the syntax
F<T>like C++ and Java?
When parsing code within a function, such asv := F<T>, at the point of seeing the < it's ambiguous whether we are seeing a type instantiation or an expression using the < operator. Resolving that requires effectively unbounded lo
Who thought it would be so hard to learn "best practices" for a table view?
From the article: https://medium.com/androiddevelopers/coroutines-on-android-part-iii-real-work-2ba8a2ec2f45
This is my list of the best Go packages I have found. They're not always the top search results.
Some thoughts on a server.
Use Jet to generate a typesafe DSL for your database and compile it ahead of time, then write Yaegi-interpreted scripts that use this DSL. Gives you editor support (code completion, linting) with fast iteration and theoretically high performance since most of the work is done in compiled Go.
| <?xml version="1.0" encoding="UTF-8"?> | |
| <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> | |
| <plist version="1.0"> | |
| <dict> | |
| <key>name</key> | |
| <string>Teal</string> | |
| <key>fileTypes</key> | |
| <array> | |
| <string>tl</string> | |
| </array> |