4 ms·
Meh. 1. How often do you insert into a slice? You know that's a O(n) operation, right? 2. nil is typed, I'll grant that it's not the most obvious part of Go's
by Jabbles 11y ago
Meh.
1. How often do you insert into a slice? You know that's a O(n) operation, right?
2. nil is typed, I'll grant that it's not the most obvious part of Go's type system.
3. Meh.
4. This is type covariance. It's complicated and hard to get right. The Java Generics FAQ looks like this: http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.ht...
5. I like by-value loops. Everything else in Go is by-value.
6. Yeah, fuck everything we know about parsing, let's make whitespace significant, then we can declare slices like:
x := []int{
1
-2
+3
}
len(x) == 3
y := []int{1 -2 +3}
len(y) == 1
7. Meh
- pcwalton 11y agoThat's not type covariance. Variance only comes up when you have generics, which Go doesn't, and subtyping, which Go doesn't really have. It's the lack of a coercion/conversion between slice-of-T to slice-of-interface. The correct language-level solution to #4 is to introduce generics and to allow generic type parameters to have interface bounds. That would solve the problem without having to introduce variance.
- mpu 11y agoIsn't it possible to talk about variance as soon as you have a type constructor (function from types to types)? In this case []. Edit: I don't know go, but if slices give write access, I think the automatic conversion the author wants would be unsound.
- pcwalton 11y agoYes, a coercion would be unsound (at least, unless the coercion copied the backing store of the slice, which would be very unintuitive). It shouldn't coerce. I'm describing generic type parameter bounds, which are not the same thing. (For what it's worth, I'm not sure I would bother solving this problem if I were suddenly put in charge of Go's design, given Go's extreme aversion to type system features. I'm just describing what the solution to this problem typically is.)
- Jabbles 11y agoI don't see how it's not type covariance. Go's slices are generic to the extent needed, and the subtyping of Go's interfaces fits the requirements for ordering of types well enough.
- pcwalton 11y agoIn Go, if T implements interface I, T is not a subtype of the interface type I. T can be converted to the interface type I, but it's not a subtype.
- sgeop 11y agoWhat's the difference though? Is this true of interfaces in Java for instance, or does it have to do with the specific implementation of go?
- infogulch 11y agoThis sums up my opinion on this pretty well. On 1 I'll just say it'd be nice if append (and other varargs functions) could take multiple of individually listed and slice-expanded args at the same time. As in: `append(a[:2], 3, a[2:]...)`. I already expect append to be O(n), and this would be some very nice sugar.
- bufordsharkley 11y agoYes, the syntax here just looks so unnecessarily ugly. For all the talk of Pythonistas moving to go, I can't see myself switching over to a language with so many ugly, hard-to-remember warts.
- telotortium 11y agoI don't know if you need to make whitespace any more significant in Go than it already is to implement 6. As you may know, Go inserts semicolons at the end of a line in the lexing phase if a token of the right type is the last one on the line (https://golang.org/ref/spec#Semicolons https://golang.org/ref/spec#Semicolons): > • an identifier > • an integer, floating-point, imaginary, rune, or string literal > • one of the keywords break, continue, fallthrough, or return > • one of the operators and delimiters ++, --, ), ], or } The things you can put as elements of a slice, values of a map, or values in a struct literal are Expressions nonterminal symbols (https://golang.org/ref/spec#Expression https://golang.org/ref/spec#Expression). As far as I can tell, the tokens that can end an Expression are a subset of those after which semicolons can be automatically inserted.