Where exactly did this land? Seems like an important conversation...
```
// RPCHandler passes RPCReq and RPCRes as fn args
func RPCHandler[T RPCReq, S RPCRes](fn func(T, S)) http.HandlerFunc {
return func(w http.ResponseWriter, r *http.Request) {
req := T{}
if err := reqBodyReadAll(w, r, &req); err != nil {
resWriteErr(w, err)
return
}
res := S{}
fn(req, res)
resWriteAll(w, r, res)
}
}
```
On Wednesday, 24 June 2020 at 17:03:51 UTC-7 ren...@ix.netcom.com wrote:
> But if you interpret the method as ‘format this struct’ a struct has named
> fields. A primitive has no named fields so the output is empty.
>
> It is almost always easier to define the contract if the method in an
> unbreakable way than rely on the compiler to catch all problems.
>
> For example what do you get if you pass an empty struct ?
>
> On Jun 24, 2020, at 6:34 PM, Pee Jai <p...@pjebs.com.au> wrote:
>
>
>
> I disagree. A type constraint for a struct would definitely provide
> compile-time guarantee that only a struct can be used.
>
> On Thursday, June 25, 2020 at 8:18:13 AM UTC+10, Ian Lance Taylor wrote:
>>
>> On Wed, Jun 24, 2020 at 12:22 PM David Finkel <david...@gmail.com>
>> wrote:
>> >
>> > On Wed, Jun 24, 2020 at 9:34 AM Robert Engels <ren...@ix.netcom.com>
>> wrote:
>> >>
>> >> Generics will not solve this fully anyway - you’ll still need
>> reflection. Why not just return empty if the user doesn’t pass a struct?
>> >>
>> > That sounds like a bug waiting to happen.
>> >
>> > I have a library with a similar reflection-related use-case involving
>> reflection, which currently panics when it gets a non-struct-type. It would
>> be nice to have compile-time type-checking, if possible.
>>
>>
>> Generics don't solve all problems. I'm inclined to say that this is a
>> problem that they don't solve. Sorry.
>>
>> Ian
>>
>>
>>
>>
>> >> On Jun 24, 2020, at 8:29 AM, Pee Jai <p...@pjebs.com.au> wrote:
>> >>
>> >>
>> >> Here is my use case:
>> https://godoc.org/github.com/rocketlaunchr/react#UnmarshalState
>> >>
>> >> That function has an argument that accepts only a struct. I use the
>> reflect package to iterate over the structs fields (and also to check if it
>> actually is a struct). The function has notapplicability for non-structs.
>> >>
>> >> Currently I have to notify the user via documentation that only a
>> struct is allowed since the type is officially an `interface{}`. This is
>> very crude.
>> >>
>> >> If there was a way to add a type constraint for only structs, then I
>> don't need to use documentation, notwithstanding the use of reflect package
>> to iterate over the struct fields.
>> >>
>> >> On Wednesday, June 24, 2020 at 10:34:40 AM UTC+10, Ian Lance Taylor
>> wrote:
>> >>>
>> >>> On Mon, Jun 22, 2020 at 7:08 PM Pee Jai <p...@pjebs.com.au> wrote:
>> >>> >
>> >>> > I can't find a way to constrain for just structs. I don't want
>> primitives.
>> >>>
>> >>> The design draft doesn't provide any mechanism for a type constraint
>> >>> to match any arbitrary struct type, and not any other kind of type.
>> >>>
>> >>> But it's not clear why that would be useful. The only things you can
>> >>> do with a value of an arbitrary struct type are things that you can
>> do
>> >>> with a value of any arbitrary type.
>> >>>
>> >>> Ian
>> >>
>> >> --
>> >> 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 golan...@googlegroups.com.
>> >> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/e86e677b-784d-47c5-b8b9-aedc37977ba5o%40googlegroups.com.
>>
>>
>> >>
>> >> --
>> >> 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 golan...@googlegroups.com.
>> >> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/8013EEB8-78E6-455D-B846-8A826682B879%40ix.netcom.com.
>>
>>
>> >
>> > --
>> > 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 golan...@googlegroups.com.
>> > To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/CANrC0BgyoPvEWJEOOrJwt-3qfLvSxc6CX9yLoYBPxYZV8GBZLg%40mail.gmail.com.
>>
>>
>>
> --
> 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...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/b15a841e-46bd-450f-8c71-d4429700b050o%40googlegroups.com
>
> <https://groups.google.com/d/msgid/golang-nuts/b15a841e-46bd-450f-8c71-d4429700b050o%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
>
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/13f26590-39ce-4153-a8d8-20d0c1036e92n%40googlegroups.com.
