Not defending Go's braindead error handling, but you'll note that Swift is doubly coloring the function here (async throws).

▲

tarentel 18 hours ago | parent | next [-]

What is the problem with that though? I honestly wish they moved the async key word to the front `async func ...` but given the relative newness of all of this I've yet to see anyone get confused by this. The compiler also ensures everything is used correctly anyway.

▲

hocuspocus 18 hours ago | parent [-]

The problem is that that the Swift function signature is telling you that someone else needs dealing with async suspension and exception handling, clearly not the same semantics.

	▲	tarentel 18 hours ago \| parent \| next [-]
		In a sense it is telling someone else that yes, but more importantly, it is telling the compiler. I am not sure what the alternative is here, is this not common in other languages? I know Java does this at least. In Python it is hidden and you have to know to catch the exception. I'm not sure how that is better as it can be easily forgotten or ignored. There may be another alternative I'm not aware of?
	▲	vips7L 11 hours ago \| parent \| prev [-]
		Isn’t the Go version also forcing the callers to deal with the errors by returning them? The swift version just lets the compiler do it rather than manually returning them.

▲

saghm 13 hours ago | parent | prev [-]

And sometimes you even have to use the return value the way the function annoates as well instead of just pretending it's a string or whatever when it's not! Having the language tell me how to use things is so frustrating.