ianlancetaylor

5 ms·

1.
by ianlancetaylor 9mo ago
Rob Pike retired from Google a few years back.
2.
by ianlancetaylor 2y ago
You can use it with other functions that use iterators. For example, here is code that makes a copy of a map keeping only the even keys. maps.Collect(xiter.Filter2(func(k, v int) bool { return k%2 == 0 }, maps.All(m)))
3.
by ianlancetaylor 2y ago
Yes.
4.
by ianlancetaylor 2y ago
The default proxy has a privacy policy: https://sum.golang.org/privacy .
5.
by ianlancetaylor 3y ago
I'm not going to claim that Go has the ideal approach to whether an error can be ignored. In general, in Go, some errors can be ignored, and some can't. For example, fmt.Fprintf to a strings.Builder can never result a non-nil er
6.
by ianlancetaylor 3y ago
Go made a deliberate decision to use multiple results rather than Option<T> or Result<S, E>. It's of course entirely reasonable to disagree with that decision, but it's not the case that the Go language designers were
7.
by ianlancetaylor 3y ago
As it happens, we considered sum types quite seriously in the early days. In the end we decided that they were too similar to interface types, and that it would not help the language to have two concepts that were very similar but not quit
8.
by ianlancetaylor 6y ago
There is no ambiguity there. The ambiguity arises for parameterized types. type A[T] int Is that a parameterized type named A with a type parameter T, or is it a definition of an array named A whose length is T? Separately, it's nice
9.
by ianlancetaylor 6y ago
Very little. The announcement here is not a new draft, it is starting the formal proposal process for adding type parameters to the language.
10.
by ianlancetaylor 6y ago
There isn't a code review for the changes on the dev.go2go branch (though you could construct one using git diff). The dev.go2go branch will not be merged into the main Go development tree. The branch exists mainly to support the tran
11.
by ianlancetaylor 8y ago
Remember that they are only pinned to an old language version. They will still work fine with new release of Go, they will just be built with the old language semantics. So what's the harm? I agree that unmaintained libraries that
12.
by ianlancetaylor 8y ago
Go could introduce a moving GC without requiring that map keys not be interface types. The simplest approach would be to use read barriers as we already use write barriers, and forward pointers during the moving phase of the GC. (Efficie
13.
by ianlancetaylor 8y ago
One step at a time. It's certainly a natural extension, and I don't think anything in the current design draft precludes it.
14.
by ianlancetaylor 8y ago
Unfortunately [T] is also ambiguous with the current Go syntax. The parser can't distinguish an array declaration from a generic type.
15.
by ianlancetaylor 8y ago
Thanks for the comments. We tried for some time to declare contracts like interfaces, but there are a lot of operations in Go that can not be expressed in interfaces, such as operators, use in the range statement, etc. It didn't seem
16.
by ianlancetaylor 8y ago
In this case the mismatch is between a type argument and the way that a type parameter is used, so it's not a type mismatch/error, it's a meta-type mismatch error. You are suggesting that the meta-type be inferred from the f
17.
by ianlancetaylor 8y ago
The blog post explains that.
18.
by ianlancetaylor 8y ago
What is an "unmarked check call"?
19.
by ianlancetaylor 8y ago
Yes, the various fmt.Print functions only return an error if Write on the underlying Writer returns an error.
20.
by ianlancetaylor 8y ago
And then the caller has to either check or ignore the error. The error never propagates to the caller's caller without an explicit action in the caller. That is unlike exceptions.
21.
by ianlancetaylor 8y ago
I don't think there is any lack of clarity about your List example; that is clearly forbidden. The example that is less clear is the one that generates a million types and then stops. A similar issue arises in C++; the C++ standard sa
22.
by ianlancetaylor 8y ago
That is not the only difference. Exceptions travel through calling functions if there is no catch clause. The check construct does not.
23.
by ianlancetaylor 8y ago
A year ago we said it was time to move toward Go 2: https://blog.golang.org/toward-go2 . This is another step in that direction.
24.
by ianlancetaylor 8y ago
Yes, what you write should work with the current draft.
25.
by ianlancetaylor 8y ago
Read the design draft ( https://go.googlesource.com/proposal/+/master/design/go2draf... ). The issues you raise are addressed.
26.
by ianlancetaylor 11y ago
The mysterious "plugin" package does not yet exist, and won't be in the 1.5 release. I would encourage you to try to implement it and send in the changes. The ideas in the execution modes doc are being steadily filled in by
27.
by ianlancetaylor 12y ago
The fact that it's not necessary to explicitly state which interfaces are implemented by a type is a key design decision in Go. It's not going to change. Every language decision has pluses and minuses. I think most Go programmer
28.
by ianlancetaylor 12y ago
I have to credit this as being one of the more original arguments for adding generics to Go: we should do it because it will increase the signal/noise ratio in discussions about Go. (Personally, I don't mind the ongoing discussion
29.
by ianlancetaylor 12y ago
I think that experienced Go programmers simply write the code using the types they need. I think the essay is entirely correct: there are certain patterns that are difficult to write in Go. It's hard to write generic code that merges
30.
by ianlancetaylor 12y ago
But it's in the map, so it's in use.

More ›