ance for the nominal
> subtype relationship). But I also think it's easy to argue that this is
> redundant and a bit confusing. And ultimately you *can* express most of the
> useful hierarchies, even if you need a bit more boilerplate.
>
Indeed I do use some boilerplate for thes
> Personally, I find "why" questions suspicious. They are usually thinly
> disguised requests to change the existing behavior. And that appears to be
> the case for this discussion.
>
No, that's not to be the case, I do imagining the change, but am not
thinking of requesting any change, I know th
>
>
> You have changed the question. You are no longer asking about defining
> methods on a type derived from a primitive type. Non-aliased types are
> deliberately distinct types that cannot be "auto downcast" or "auto
> upcast". Arguably the biggest flaw of the C language was its automatic type
>
> Adding methods to a primitive type, or more generally adding methods
> to a type defined in a different package, would cause different
> packages to behave differently depending on whether they see the
> methods. That would be confusing. It would meant that type
> assertions would sometimes suc
On Fri, 20 Oct 2023 at 07:51, Ian Lance Taylor wrote:
> On Thu, Oct 19, 2023 at 5:14 PM Jason E. Aten wrote:
> >
> > Analogous to
> >
> > type IntSlice []int
> >
> > func (p IntSlice) Len() int { return len(p) }
> > func (p IntSlice) Less(i, j int) bool { return p[i].val < p[j].val }
> > func (p
f42e2/keys.go#L44
>
>
> On Nov 19, 2017, at 11:49 AM, Nurahmadie Nurahmadie
> wrote:
>
> Hi Chandru,
>
> I made a library to support openssh ed25519 key format.
> It can be used as a drop-in replacement of `ssh.ParsePrivateKey` as shown
> here: https://github.com/fudanchii
Hi Chandru,
I made a library to support openssh ed25519 key format.
It can be used as a drop-in replacement of `ssh.ParsePrivateKey` as shown
here: https://github.com/fudanchii/edssh
On Thu, Nov 16, 2017 at 11:43 PM, me via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> x/crypto/ssh does s
