Might have come across this today as I was trying to simplify some code.
Basically, I have a base type called *Element that has a method AsElement()
*Element that returns itself.
And this base element is used as a base for many others, for isntance:
type Div struct{ *Element}
type Span struct{*Element}
type Anchor {*Element}
...
Somehow, I need a function Ref that can take a pointer to any of these
elements and modify them (basically modifying the inner *Element pointer).
Currently, I don't think I can abstract over these types which share in
common the *Element field and the AsEleemnt method promoted from it.
I don't want to have to implement a specific method to do that mutation
operation for each and every one of these types either.
Basically, trying to make generic this function:
func Ref(vref **Element) func(*Element) *Element{
return func(e *Element)*Element{
*vref = e
return e
}
}
Or does anyone see something that I missed?
On Thursday, April 4, 2024 at 2:52:16 AM UTC+2 Adam Manwaring wrote:
> While this would make some things much easier for me, it seems this would
> be a pretty fundamental change. Constraints are essentially interfaces and
> interfaces in Go are defined by behaviors. Structs, on the other hand, are
> defined by properties. There is no behavior that all structs have that
> every other type couldn't also have. Thus having a struct constraint would
> be a one-off exception which for the most part seems anathema to Go. In a
> similar vein, there are many times I'd like an interface to require certain
> exported properties in addition to behaviors, but this isn't going to
> happen.
>
> On Wednesday, March 27, 2024 at 6:28:19 PM UTC-6 Makis Maropoulos wrote:
>
>> Same here @Abraham,
>>
>> ResponseType interface {
>> ~struct{}
>> }
>>
>> Obviously this doesn't work, I would love to see it working though.
>> On Wednesday 14 September 2022 at 17:48:19 UTC+3 Abraham wrote:
>>
>>> I am glad I found this thread because I was just now breaking my head
>>> figuring out why my <struct constraint> was not working....
>>>
>>> On Wednesday, May 18, 2022 at 10:41:29 PM UTC-4 Ian Lance Taylor wrote:
>>>
>>>> On Wed, May 18, 2022 at 7:36 PM Jeremy Kassis <jka...@gmail.com>
>>>> wrote:
>>>> >
>>>> > Where exactly did this land? Seems like an important conversation...
>>>>
>>>> To date there is no way to write a constraint that requires that a
>>>> type argument be a struct type.
>>>>
>>>>
>>>> > ```
>>>> > // 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)
>>>> > }
>>>> > }
>>>> > ```
>>>>
>>>> I would write simply "var req T" and "var res S".
>>>>
>>>> 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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/f2150cf5-75d9-4cb3-9a29-d5a8c8e655a5n%40googlegroups.com.
