On Sat, Jun 20, 2020 at 10:48 PM Jon Reiter <jonrei...@gmail.com> wrote:
>
> the draft lays out an example function GeneralAbsDifference. these comments
> build around that. i wanted to see how far i could get towards working
> specialization within this framework. the baseline assumption is that when
> specialization is required today the acceptable amount of type
> switching/assertion goes up a bit.
>
> so the simplest variation is
> func GeneralAbsDifference(a,b interface{}) interface{} {
> ai, aiok := a.(int)
> bi, biok := b.(int)
> if aiok && biok {
> return OrderedAbsDifference(ai, bi)
> }
> // repeat for all types
> }
>
> that works but is, even given the qualifier above, not really acceptable.
> you can make it a bit cleaner with reflect but still, it's bad. changing
> interface{} to Numeric doesn't work with compile error "interface type for
> variable cannot contain type constraints". fair enough, although i'm not
> convinced no such useful check is possible at compile time. with that
> facility available it's debatable whether some of those
> otherwise-not-so-clean setups are worth it in exchange for only having to
> write the underlying absdiff() functions once each.
>
> if we pretend the arguments can be of type Numeric we can try our type logic
> as:
> ao, aook := a.(OrderedNumeric)
> ...
> in hopes of getting a somewhat-cleaner arrangement. this, with a and b using
> interface{} so it could otherwise compile, returns the entertaining error
> message "OrderedNumeric does not satisfy OrderedNumeric." and it is true
> that type does not appear in the type list of the interface. in this case
> there are two arguments and we'd need to ensure they are of the same
> acceptable type. i was expecting this to compile and then to write some
> logic using reflect and see how badly it turned out. that's not an option.
>
> but consider this for a single-argument function. then there is no
> uncertainty -- the logic i'd need to write is straightforward and can surely
> be automatically generated. i think that is true whenever each type
> parameter specifies only 1 argument's type. multiple-argument
> generic-specialization would then require creating "tuple interfaces" that
> glue the params together but would be otherwise clean and explicit. it's
> certainly better than what you'd need to do today to handle any of this.
>
> so two specific questions:
> - is there some part-way use of types in interfaces that can be used in
> non-generic function arg specs? in this case the return value would require
> it but in general arguments-only would be useful too.
Possibly such a thing could be defined, but it's not in the current
design draft. And I'm not sure it would help. If I write F(a, b
Ordered) then both a and b may be Ordered, but nothing requires that
they be the same ordered type.
> - at least for cases where no ambiguity exists is it possible for a
> type-containing interface to act like it's on it's own type list?
I guess I'm not sure why you need this. If you have a type list, it
seems feasible to type switch on each possible type. I'm sure I'm
missing something.
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/CAOyqgcXpAU0k-uMncrgbRpjMTyoeiui-po%2B35zvzJD3nYnXktg%40mail.gmail.com.
