This question frankly struck me odd, given the context. To paraphrase: "Do I have examples of where accessing a field in a generic struct type might be useful?" I kind of assumed that, hip-deep as we are in a discussion of generic functions, that such a thing might be understood? I mean, accessing struct fields in functions is ... useful? Would not accessing struct fields in generic functions be ... similarly useful? I am honestly befuddled.
1. The draft proposal discusses the Corresponding function, to assign fields of the same name from one struct to another, of different types (here <https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md#fields>). The function looks like this: func Corresponding(type T1, T2 counters)(p1 *T1, p2 *T2) { p1.Count = p2.Count } 2. To quote the draft proposal, "ever popular Min and Max functions", as applied to structs. Somewhat to my surprise, the draft doesn't actually give a sample implementation of these, at least not that I could find. So here's my attempt: contract key(x T) { x.Key < x.Key // specify that T must have a Key field and that it must be ordered } func MinKeys(type T key)(x, y T) T { if x.Key < y.Key { return x } return y } So, I think accessing fields of generic struct types would be handy, yeah. — L On Tuesday, September 11, 2018 at 6:54:06 AM UTC-4, Jonathan Amsterdam wrote: > > Do you have actual examples of how that would be useful to you? > > On Monday, September 10, 2018 at 9:45:12 PM UTC-4, Larry Clapp wrote: >> >> The conversation here is deep, and I haven't followed all of it. I >> *think* y'all are discussing some different contract system than the >> actual draft proposal? >> >> If that's the case: >> >> You can't express field-accessors, which is an actual, inarguable >>> reduction in power that I'm perfectly fine with >> >> >> How would you instantiate a generic function that wanted to access field >> F of a generic type T? >> >> if you can't do that, well, I'm not fine with that. >> >> But I may have misunderstood. >> >> — L >> >> On Monday, September 10, 2018 at 7:45:04 PM UTC-4, Axel Wagner wrote: >>> >>> The unambiguous cases aren't ambiguous of course. It's the ambiguous >>> cases I'm concerned about :) My post and this thread contain a bunch of >>> those. They are mostly growing out of builtin functions and things like >>> `range` statements and index-expressions. >>> >>> You can translate all of my "pseudo-interfaces" into a clear and short >>> contract >>> >>> contract comparable (v T) { v == v } // also allows != >>> contract ordered (v T) { v < v } // also allows <=, >, >= >>> contract boolean (v T) { v || v } // also allows &&, ! >>> contract bitwise (v T) { v & v } // also allows |, ^, <<, >> >>> contract arith (v T) { v * v } // also allows +, -, / >>> // well, this one's a bit harder… >>> contract concat (v T) { v + v; v == "" } // also allows range, >>> index[int], copy >>> contract complex (v T) { real(v) } // also allows imag(v) >>> contract nilable (v T) { v == nil } // also allows != nil >>> >>> There is some discussion about maps, slices and channels to be had - but >>> I think the vast majority of interesting cases can be covered by taking >>> e.g. a `chan T`. A defined type with underlying type `chan T` is assignable >>> to that, so it would appear a perfectly fine way to express this contract >>> contract Chan (ch C, el T) { var x T = <-ch; ch <- x } >>> (and correspondingly for send/recv-only channels). >>> >>> You can't express field-accessors, which is an actual, inarguable >>> reduction in power that I'm perfectly fine with (similarly to how we're >>> fine with interfaces not being able to express that). >>> >>> Which IMO brings up the question: If we can express the vast majority >>> (or even all) of the needed contracts as combinations of this handful of >>> base-cases, why would we need to allow the full power of Go syntax, which >>> enables to write all the less than obvious ones too? >>> >>> (to re-emphasize: All of this isn't polished. I did sanity-check against >>> the examples in the contract design doc, but I have not put enough thought >>> into it that there might not be a couple nooks and crannies I haven't >>> thought of, as you've proven before :) ) >>> >> [snip] -- 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.
