On 2018-01-13 01:35, Axel Wagner wrote:
> But the answer to 2 is "no, not in a type-safe way". It necessarily
> requires reflection. Even if we'd assume we somehow magically know that
> the dynamical value of the interface is some pointer type. That doesn't
> actually help us, in any reasonable way. We can dereference it, but we
> wouldn't know what the thing it's pointing to is. Or to put it another
> way: To dereference a pointer, you'd have to know - at the very least -
> the size of the thing it's pointing to.
Which we do. It's a pointer.
> And to do it in a type-safe way,
> you'd have to know the /type/ of the thing it's pointing to.
Or just ensure the type T is the same for *T as it was for **T
I can't see that's ambiguous in the common language sense of the word.
> Yes, in theory, the compiler an inspect the type-info of the interface,
> see that it's a pointer-type and then construct a new interface-value,
> with dynamic type "type of the pointee" and dynamic value "pointee" -
> that's reflection. I.e. the compiler would emit code for the equivalent of
> v := reflect.ValueOf(v).Elem().Interface()
> That is the best you can do, but in particular, you don't have any
> static information about what the value is you are operating on, so you
> can't call any methods on it, you can't dereference it, you can't do…
> anything with it, really. Like, you can't actually do any better than
> what reflection gives you - and reflection already works.
My point about that the dereference operation was the only meaningful
one was exactly because there's no static type info. As I said you
probably can't write a function, but a language *could* in theory define
an operator which would turn any **T into a *T, regardless of type.
> Your request is essentially equivalent to reflection as a
> language-feature, which is essentially equivalent to making Go a
> dynamically typed language.
It was not a feature request.
I just posed the question out of curiosity. The rest of the discussion
has been about whether it was ambiguous.
If a language (in theory) provided an operator which would only act on
variables of type Pointer-To-Pointer-To-T and returned the Pointer-To-T,
I can't see how that would be ambiguous. And it could still do the same
level of static type checks as Go does with interfaces.
> template<class T>
> T *f(T **p) {
> return *p;
> }
>
>
> This is not the same. In the case of this C++ code, the actual type of T
> is statically known.
I know .. I said it was cheating.
My point with that example was to say that it's not ambiguous (*in the
common language sense of the word*) what is meant.
You can state it and there's no doubt what is meant.
/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.
