I seem to keep running into situations where I have a function like:

func Thing(...) (interface{}, error) {

Which I then do this with:

x, err := Thing()
y := x.(AppropriateType)

I know this is related to the whole generics thing and I'm not interested
in that at all. I'm interested in know why this would be a bad idea to

x, err := Thing().(*Type, error)

Ie. Support a type assertion in the form (T1, T2, ...) that could be
invoked on a multi-type return from a function.

I *did* go and read that ancient epic thread about this, but honestly the
only real objections to this I could see were:

1) .(T) is a multi return type itself, in the form T, ok := blah.(T)

(comment; this isn't relevant; it's already a special case in that you can
x := blah.(T) without having to x, _ := blah.(T)

2) If you support the syntax of func().(T) it's arbitrary which of the
return elements should have the type assertion attached.

(comment: I'm not suggesting this at all; I'm suggesting the type assert
must be of equal length to the function return set)

So, long story short: Can anyone succinctly why this would be either 1)
inconsistent, or 2) a Bad Thing (tm).

There's a lot of redundant code out there that could go away with this.


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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

Discussion Posts

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 1 of 3 | next ›
Discussion Overview
groupgolang-nuts @
postedMay 18, '13 at 1:36a
activeMay 19, '13 at 12:31a

2 users in discussion

Dougx: 2 posts Nigel Tao: 1 post



site design / logo © 2021 Grokbase