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. 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?
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/CAOyqgcVfKyH0cjE3_amBKPQMCT0J%3DaOtDc4kBd9MbtdzEQBc_g%40mail.gmail.com.
