On Mon, Aug 10, 2020 at 8:30 PM Ian Lance Taylor <i...@golang.org> wrote:
> On Mon, Aug 10, 2020 at 6:07 AM Markus Heukelom
> <markus.heuke...@gain.pro> wrote:
> >
> > 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.
>
> Go is a strictly typed languages, and constraints are the meta-types
> of type parameters.
I just realised there might be a distinction between strictly typed and
strongly typed languages. Would it be correct to say C++ is strongly typed,
but not strictly typed wrt templates (up C++20 at least)? Did you mean it
in that sense?
You are suggesting that we should have an escape
> hatch for that meta-type system when using unexported types. I
> suppose that is possible. It seems like something we could add later
> if it brings a big benefit.
>
>
I'm not sure when your example would really arise. It looks like you
> have a tree type; why not make that a parameterized type and make
> sibling a method on the type?
>
>
Mainly for intrusive containers, see for example
https://www.boost.org/doc/libs/1_73_0/doc/html/intrusive.html
In my case I have two multi-index containers that are only used internally.
They use the same rebalancing algorithm and some other stuff for
adding/removing nodes, but I couldn't factor that out with the current
generics design. Well tbh I could define an interface maybe with getters
/setters for the fields but it feels a bit silly for internally used only
stuff. I do agree that it's very niche probably and it does not warrant the
addition of fields to interface constraints.
> 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/CAMoB8rWscmR3vQA5LFHpTPV4KhJzggUszF2HKUA-LoMFNfkoHA%40mail.gmail.com.
