On 2018-01-12 22:22, Axel Wagner wrote:
> Yes, you can *test* if the dynamic value has a specific type (and
> extract it if so). That is not the same as operating on the dynamic
> value (e.g. by dereferencing it) *without* knowing its type.
I know I can test the type. But the issue was specifically to
dereference the first pointer while keeping the actual object.
> Go does not have parametrically polymorphic types - and even if it had,
> there wouldn't be any sensible type you could assume here, given that
> it's only known at runtime. There simply is no type that the extracted
> value could have. Like, what would the type of t be in your example, in
> the **<Something> case?
It seems we are constantly talking pass each other. There was two
questions here
1) Can it be done in Go as the Go spec is now?
2) Is it in general an ambigious task?
So let's assume we already have answered 1) with "no". (I guess)
It seems you are trying to argue that the answer to 2) is "YES", but
doing it with reference to current Go spec.
I'm perfectly aware that in a case in a type switch like this
switch t := i.(type) {
}
... t needs to have a type in each case clause, and the only type it can
have in lack of a specific type mentioned, is interface{}
But still ... that's an argument for 1) - not for 2)
> Yes, it is in general ambiguous what is meant.
No, I don't think so.
There nothing ambigious about generic operation of turning **T into *T.
The only reason it cannot be done here is because the deference operator
needs to operate on a concrete type and we have an interface{}.
It might not be meaningful to define an actual generic function
mechanism for this, since for the compiler to check the types there is
not much more than the dereferencing which can be done
But it is possible to state this in C++:
template<class T>
T *f(T **p) {
return *p;
}
... however, templates are kinda cheating.
... and that was all I was saying by it not being ambiguous.
> You /can/ generically dereference a pointer, but you have to use
> reflection, which is the tool to be used on generic values that you
> don't know the type of: https://play.golang.org/p/73lJyOlaIdL
Ahh... yes... I think I overlooked the Elem() method. It seems it allows
me to make an interface value of *T from an interface containing **T
without knowing the actual type of T.
... so the answer to the question is actually "yes" - that can be done
without unsafe.
> I consider it unlikely that you actually want to do that, though. Unless
> you are writing some generic encoder, that can operate on any type.
That's actually the case - or at least and decoder for now.
> But
> the fact that you are asking about doubly-indirect pointer and
> dereferencing them one layer deep, seems to suggest that you actually
> want to use a specific type because you know what types you can have.
No... If I knew the type, I would have said it.
However... I'm still not sure whether it actually solves what I'm trying
to do. But it did answer the question I posed out of curiosity.
Thanks,
Peter
--
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.
