On Sun, Jul 19, 2020 at 3:16 AM Ian Lance Taylor <i...@golang.org> wrote:
> On Sat, Jul 18, 2020 at 4:55 AM Markus Heukelom
> <markus.heuke...@gain.pro> wrote:
> >
> > Concerning the current generics proposal, was it every considered to not
> allow type contracts at all?
> >
> > No type contracts would mean that generic functions can only use =, & on
> variables of parametric types, as these are always available for all types.
> Nothings else is allowed.
> >
> > This would remove the possibility to write generic mathematical
> functions, for example. But it is simple and it already enables a lot of
> usefulness. Was this considered too restrictive?
> >
> > Type contracts could optionally be added in a later stage, but at least
> at that point we will have a larger body of generic code to work and test
> with.
> >
> > A bonus, disallowing all operations except assignment and address-taking
> would maybe also stop abuse of templates in the name of "but it is more
> efficient than interfaces" and "fancy coding syndromes".
>
> I think that for a language like Go any generics implementation must
> permit people to write the functions Min and Max. The functions are
> trivial, but they are among the first that programmers accustomed to
> generics complain about in Go.
>
>
For what it is worth: for non-exported functions/types all operations could
be allowed, possibly leading to infamous C++-level error messages but as
you are the author of the package, those error messages would make sense to
you anyway.
For example, I could really use to be able to write things like this:
func sibling[type t](node *t) *t {
if node.parent == nil {
return nil
}
if node.parent.left == node {
return node.parent.right
}
return node.parent.left
}
This is not really possible with the current design. Of course I could
specify an interface with getters/setters, but that feels a bit silly and
cumbersome as everything is local to the package anyway.
I don't have better a solution, but all contracts/constraints do is prevent
long, unreadable error messages while inside a package there's no real
problem with those error messages to begin with.
> 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/CAMoB8rWFa7ifAogg5i0A%3DZbtFAVDwKLX9nh98FyYuxCafKo%2BdQ%40mail.gmail.com.
