On Wednesday, 20 January 2021 at 10:53:10 UTC axel.wa...@googlemail.com
wrote:
> On Wed, Jan 20, 2021 at 11:08 AM Brian Candler <b.ca...@pobox.com> wrote:
>
>> What I mean is, the difference between
>> func f(a, b fmt.Stringer) c fmt.Stringer { ... }
>> and
>> func f[T fmt.Stringer](a, b T) c T { ... }
>> would simply be that a, b and c had to be of the *same* concrete type -
>> but were otherwise still interface values (and specialisation, if
>> implemented, would just be a hidden optimisation).
>>
>
> The only thing standing in the way of that is the requirement to enable
> operator usage. You can't use `+,<,*,…` on interface values, so if you
> require the design to support using them
>
Yes. Conceptually at least, interfaces defined as type lists could be used
as interfaces:
type Foo interface { type int32, int64 }
func f(a, b Foo) {
if (a < b) ...
}
Without specialisation, there would be dynamic dispatch. Internally it
might work something like
if (a.__lt__(b)) ...
At worst the __lt__ function for int32 uses reflection to check its right
argument is int32. However I believe go always requires that both
arguments to "<" are the same type, so the compiler itself can check that.
In the above example this can be elided because it knows a and b are the
same type; at worst it adds a run-time check.
Untyped constants are a problem though:
if (a < 3) ...
>
> And FWIW, the design intentionally doesn't imply implementation choice -
> that is, in general, a compiler should be free to choose a pure boxing
> implementation already and AFAIK that's how the prototype works. That
> boxing implementation is more complicated though, than simply "put things
> into interfaces", because you need to provide access to operators.
>
>
And parameterised types are still required, e.g.
type mycontainer[T any] []T
I am just wondering aloud if if it could be broken down to a set of
orthogonal extensions:
1. Type parameters to functions (which can constrain interface arguments to
have corresponding types)
2. Type parameters to types
3. Type lists in interfaces
That leaves generic specialisation as an internal optimisation, which in
principle could apply to all interface arguments - although this would need
to be controlled. e.g. you might not normally want to recompile large
chunks of standard library which passes around io.Reader.
--
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/bc0aa77d-42a2-4f3f-bd9c-a756b43b6fe9n%40googlegroups.com.
