did you do the full pipeline?
I did not, because every step of the way, I keep running into the same
limitation - reflective meta-programming doesn't work without explicit
field-references, in some form or another.

As explained, not everything can be batched together - any operation where
you wish to designate a specific field explicitly, is impossible without
(currently) referencing the field-name as a string.

I posted a (very loose) feature request here:


Of course there are other ways, but they are all indirect - if I'm going to
associate data with source-code elements, I need some way to reference
those source-code elements to get to that metadata. Currently, you can
reference a type as reflect.TypeOf(Foo{}) but there is no way to reference
a field, only it's value.

At this time, I am leaning away from using annotations/tags on fields at
all, because there is no direct way to get to the data - only indirectly,
by iteration.

I still don't get[0] why you're attempting to reference a field by
name (and then complaining about your choice) when there are other
ways, discussed earlier, which never mention the name of the field as
a string (literal) value. Some of them are even typechecked statically
(eg. taking a pointer to the field).

Again, you are passing pointers to the field's value, disconnected from the
field itself - thus already no way to get back to e.g. an annotation/tag on
that field.

In other words, no matter which of the discussed approaches you choose,
currently, you lose something every time - I need some way of passing the
full information, intact, type-checked.

As said, strings will do it - and in e.g. PHP that's what I'd be doing,
since it doesn't have this feature either. But in PHP, everything is
loosey-goosey, untyped and unchecked, and you expect run-time errors -
since Go is statically typed and compiled, the loosey-goosey approach of
referencing fields by name, using strings, feels dirty and wrong. But I
don't think that means reflective meta-programming is wrong and shouldn't
happen in Go?

On Monday, January 13, 2014 9:49:29 AM UTC-5, egon wrote:

What you have experimented on or how far have you gotten? But did you do
the full pipeline? :)

I'm asking because my intuition tells me that when you put the whole thing
together that either your compile-time checking falls apart or you can
automatically batch things per struct and avoid the whole referencing

+ egon
On Monday, January 13, 2014 3:50:14 PM UTC+2, Rasmus Schultz wrote:

I still find the lack of any ability to reference a field in a struct is
sort of crippling - everything else feels like a work-around.

Because you have the source-code elements already, inventing "something
else" (whatever that is) so you can attach information (metadata) to those
source-code elements, is always going to feel like a work-around - strings
as field-names are awkward and unreliable, because you have a way to
reference fields already, it just doesn't "work".

No matter what else I come up with as work-arounds for various problems,
this is lacking.

I also noticed the Alignof() and Offsetof() functions in the unsafe<http://godoc.org/unsafe>package, and look: they get to do it!

Offsetof returns the offset within the struct of the field represented by
v, which must be of the form structValue.field. In other words, it returns
the number of bytes between the start of the struct and the start of the
There is only one way these functions are getting both the struct and the
field passed to them - these functions are not real "functions" in the Go
sense, and what you're passing to these function-calls is actually two
arguments, the struct and the field, although for these special functions
you get to write it as one actual argument.

That's what I'm missing.

So you can argue it's not necessary and that there are other ways to
solve my problems, but there isn't really - there is currently only one way
to designate a field (not it's value) in a struct, and that is by using
strings. In a statically-typed language, using strings to reference types
should not be necessary.

I think I will try to summarize this stuff in a feature request, because
clearly Go itself needs this functionality and had to create some internal
work-around to get it - this "ArbitraryType" type, which isn't a real type,
and doesn't work in userland.

I learned lots of other useful things from this conversation, but I also
learned that there is no (reliable) way to reference fields for the
purposes of reflection.

I think that needs to be fixed.

On Tuesday, December 31, 2013 7:54:54 PM UTC-5, Rasmus Schultz wrote:

Is there any way to *statically *reference a type or member?

Something like a typeof() operator or something?

I realize something like reflect.TypeOf(Foo{}).FieldByName("xyz") is
possible, but the field-name can't be checked at compile-time...

Any other alternatives?
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



site design / logo © 2022 Grokbase