I think that the issue with dealing with multiple conditions and certain pre-defined response patterns is at the centre of the error handling problems.
My suggestion is here: https://github.com/golang/go/issues/27794 and centers around extensions of the return and switch syntax. The solution I am suggesting is adding a conditional to return statements (tacking on the head of an `if` statement to the end of a return), a multiple return case structure that resembles a map literal declaration, and adding another (maybe 'if') header to switch blocks for implicit fallthrough. Switch blocks already have 'case' and 'default', I am suggesting add 'if' to be a 'fallthrough' block. The conditional returns are because very often the main response to an error is to either panic or return an error value, but only in a particular case. I think if the if syntax is fully repeated (except with the statement only being between the return and if), this also means being able to use the `..., ok ` which would serve to act as a shorter version of a type switch for interface{} variables. For this maybe a special syntax as well. I think that with these changes in place, a lot of the reasons for wanting generics would also be reduced. Type switches are a little boilerplatey and the lack of a conditional return means you have to often write a lot more lines of code, often involving if statements, when maybe your function only wants to handle one type (for now) and a default case. The most direct cognate in Go for generics is the interface{}, so making common operations and conditional branches around checks, fallthroughs and returns eliminates a lot of the wordiness of Go's support for generic typing. I still don't think generics are needed, as to me the []byte is already fully generic. Writing methods that make this easy, and designing the scaffold of interfaces to allow easily welding together two different types that work on a (same but differently formatted) similar data type, such as really big numbers, or strings of symbols, collections of predefined types (without metadata) or typed collections, is not that difficult. The other thing is I think that all types more complex than 64 bit integers should have an implied error status variable (thus implicitly being a struct), as this reduces the need to use chain-breaking tuple returns. Actually, I didn't mention the implied error value in all structured types in the issue I made. I have just made my own type that I can embed into anything I need to track an error as well as be able to chain simple, usually one or zero parameter methods together. I think that this is not a language side issue, more to do with a built-in interface. I think 'error' should also have metadata- and non-metadata serialisation functionality built in as well as set and clear functions. The serialisation functions can be easily overridden - when I talk about how in many cases solutions to issues in Go have to do with understanding the right pattern to use for a particular situation, that eliminates the need for a change in the syntax. It seems to me this is how the Go authors look at these things too - the cost of increasing compilation complexity, reducing interactivity and basically just wasting time, over issues of structure and readability that are just a lack of knowledge, in fact... so I think that these kinds of changes, as I am suggesting, are the more likely to be finally chosen, as they extend patterns a go programmer is already familiar with, they don't substantially change the parsing complexity. They keep in the same vein and continue consistent patterns found elsewhere in the language as well as presenting a more simple, but expressive solution than used in other languages. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
