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.
- 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?
some type logic is always going to be necessary given the language setup.
i just want to avoid having to write purely-mechanical if-else blocks to
appease the compiler here, or using interface{} and throwing out compiler
assistance.
this feels adjacent to the discussion on "identifying the matched
predeclared type" but my comment is already too long so i'll stop there.
--
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/CABZtUk6W4t1T%3D%3DMC7xRh35RH-_51fq1fZoAR9qSA9KK-wtddRQ%40mail.gmail.com.
