121–125 of 125 posts
Earlier quoted context omitted.
Any plans to add formal sum types (as opposed to interface hacks)?
Definitely something I'm thinking about. It's one of a handful of features that I have in my head but haven't created an issue for.
You have one now: https://github.com/albrow/fo/issues/7
:)
Earlier quoted context omitted.
Did you consider parameterized packages? The idea is you can declare a set of related objects/types/methods as well as have concrete type specific initialization. E.g. package stack[t] type Type []t func New() Type { return Type{} } ... Then it can be used so: import s “stack”[int] var s1 = s.New()
Parameterized packages are interesting but they come with their own problems. It can get tedious if I want to use, e.g., a stack with multiple different types. They also lose some of the flexibility that comes with scoping type parameters to any function/method/data structure.
I liked certain aspects of Go, but lack of generics was a deal-breaker for me. You approached it a way better than I (and many others) did. Instead of arguing on forums you started writing code.
Earlier quoted context omitted.
This is how I understood the use for panics: https://stackoverflow.com/questions/44504354/should-i-use-pa... > You should assume that a panic will be immediately fatal, for > the entire program, or at the very least for the current > goroutine. Ask yourself "when this happens, should > the application immediately crash?" If yes, use a panic; > otherwise, use an error. In Java, say, exceptions are the standard for rai…
If want (and if it makes sense) you can use panics as a control flow mechanism to quickly bubble up errors inside your implementations. See an example in the standard library itself: https://golang.org/src/encoding/json/encode.go , line 295 What's frowned upon is leaking this out of your package's interface/contract.
Java/Python encourage the use of exceptions as returning error conditions, rather than return error codes.
Earlier quoted context omitted.
Can you do ad-hoc or bounded polymorphism? What about recursive types?
Yes, I've already been thinking about constraining type parameters to an interface. Internally, the type-checker considers type parameters to have underlying type interface {}. A constraint on a type parameter should be as straightforward as changing it's underlying type to a specific named interface instead of an empty one. The only tricky bit I can see is thinking about how this would work with generic interfaces o…