On Wed, Jan 20, 2021 at 11:08 AM Brian Candler <b.cand...@pobox.com> wrote:
> With my wild hat on: it makes me wonder what would happen if the generics
> proposal became nothing more than interfaces with linked constraints - so
> that you could say "this function takes a function of type T (interface C)
> and returns *the same type* T", or "this function takes a []T and returns a
> value of *the same type* T".
>
> 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, the design *must* somehow encode
a notion of specialization. I think if you'd remove that, the design is
pretty much what you describe here (and, of course, it wouldn't require
type-lists).
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.
> The obvious problem is that if you actually pass interface values around,
> then many type-mismatch violations couldn't be detected until runtime.
>
> However: I find the same problem occurs with the current generics
> implementation, *if* you pass interface variables. Check this out:
> https://go2goplay.golang.org/p/F08gh5gotsO
> Print2() expects that both arguments are of the same type - but in the
> final call, they are not! There is neither compile-time nor run-time error.
>
> ISTM that constrained interface types *could* also be checked at compile
> time, in the common case where the caller passes concrete types. Rewriting
> to use plain interfaces instead of generics:
> https://go2goplay.golang.org/p/CfkvAcgr8mC
> I think that an interface type constraint system *could* statically check
> that both args of the first Print2() call were (or were not) the same type.
>
> What you might end up with is linked type constraints being a natural
> extension of interfaces. Generic specialisation would just be an
> optimisation on top of that (if the call site knows that a particular set
> of concrete types is being used). Type lists could also become an
> extension of interfaces.
>
> However, that's just off the top of my head. Whilst I've been following
> generics intermittently, no doubt this has been considered (and discarded)
> before.
>
> Regards, Brian.
>
> --
> 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/34bdb40e-ad0b-47ce-8588-d014d0886470n%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/34bdb40e-ad0b-47ce-8588-d014d0886470n%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/CAEkBMfEGnbsi1-G1vde_zyvx0Q85bRz3KCyd4e-rKm0%3DJr9R4w%40mail.gmail.com.
