FAQ
http://blog.golang.org/laws-of-reflection
by Rob Pike, so its good ;)

Am Freitag, 25. September 2015 01:28:59 UTC+2 schrieb Gbr:
Ran into a problem where an interface of underlying type "string" is
silently converted to an interface of underlying type "reflect.Value". And
an eventual panic message pointed to a completely different location/cause.

Simplified Play example. <https://play.golang.org/p/8fhaf1LMRW>

Raised a number of questions

A typed interface, X in this case, is not type specific to its underlying
type? Seems so, since the problem assignment

x = mischief(x)

does not cause an immediate error even if x is explicitly created by

x := reflect.ValueOf(s).Interface()

Is there a reason not to extend the type system to verifying the type of
at least the first level of underlying type of an interface value?

The promotion of a value to an interface does not promote the underlying
type value to the interface when the value is already a reflect.Value?
That is, reflect.Value is nominally an underlying type value container.
Does an interface value with an underlying type of reflect.Value ever make
sense? If it does, seems like there should be some path for getting at the
second level underlying type

x = mischief(x)
x = reflect.ValueOf(x).InterfaceOfNextLevelUnderlyingType()

Is there an existing reflection way of doing 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/d/optout.

Search Discussions

Discussion Posts

Previous

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 5 of 5 | next ›
Discussion Overview
groupgolang-nuts @
categoriesgo
postedSep 24, '15 at 11:29p
activeSep 25, '15 at 10:12p
posts5
users3
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase