On Fri, 20 Oct 2023 at 16:58, 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> FWIW I think what OP is ultimately asking about is some form of nominal
> subtyping. When they say "automatic upcasting", they refer (I believe) to
> what Go calls "assignability", which is in essence a subtype relationship.
> So they want to be able to define a new type, that is a subtype of an
> existing type, but add some methods to it.
>
Yes, this is generally what I meant, thank you for rephrasing it more
precisely.
> And - controversially, perhaps - I don't think they would be anything
> inherently wrong about it. Except that it means we'd have two ways to have
> subtyping in the language.
>
> First, I agree with other posters here that it would be bad if `type
> String string` would create a subtype relationship between `String` and
> `string`. Ultimately, we do want to have the ability to create genuinely
> new types, with no relationship between them. It's an important safety
> mechanism.
>
This statement doesn't feel right to me, one can always do `type NewType
struct{}` to create genuinely new types, but if you do `type String
string`, for example, surely you expect String to has `string` value, hence
there will always be a relationship between them? I might be missing
something obvious here.
> But we could imagine having a new form of type declaration, say `type A <
> B` (syntax only illustrative) that would create a new type `A`, which
> inherits all methods from `B`, could add its own and which is assignable to
> `B` (but not vice-versa). We basically would have three kinds of
> declarations: 1. `type A B`, introducing no subtype relationship between
> `A` and `B`, 2. `type A < B`, which makes `A` a subtype of `B` and 3. `type
> A = B`, which makes them identical (and is conveniently equivalent to `A <
> B` and `B < A`).
>
I think it's perfectly makes sense if we resort to nominal subtyping given
the new declaration, but I'm genuinely pondering about the existing
structural subtyping characteristic instead, and I'm not trying to change
anything about Go from the discussion. :D
> I think this would honestly be fine and perfectly safe. You'd still have
> to explicitly declare that you want the new type to be a subtype, so you
> don't get the weak typing of C/C++. And the subtype relationship would only
> "flow" in one direction, so you can't *arbitrarily* mix them up.
>
> Where difficulties would arise is that it naturally leads people to want
> to subtype from *multiple* types. E.g. it would make sense wanting to do
>
> type Quadrilateral [4]Point
> func (Quadrilateral) Area() float64
> type Rhombus < Quadrilateral
> func (Rhombus) Angles() (float64, float64)
> type Rectangle < Quadrilateral
> func (Rectangle) Bounds() (min, max Point)
> type Square < (Rhombus, Rectangle) // again, syntax only illustrative)
>
> The issue this creates is that subtype relationships are transitive and in
> this case would become *path-dependent*. `Square` is a subtype of
> `Quadrilateral`, but it can get there either via `Rhombus` or via
> `Rectangle` and it's not clear which way to get there. This matters if
> `Rhombus` or `Rectangle` (or both) start overwriting methods of
> `Quadrilateral`. The compiler needs to decide which method to call. Usually
> it does that by defining some tie-breaks, e.g. "use the type named first in
> the subtype declaration". But there is a lot of implicity there and with
> deeper hierarchies, you can get spooky breakages at a distance, if some
> type in the middle of the hierarchy does some seemingly harmless change
> like overloading a method. Look up "Python Method Resolution Order" for the
> kinds of problems that can arise.
>
> Structural subtyping does not have these issues, because the subtype
> relationship is completely determined by a subset relationship - in Go's
> case, sets of methods of the dynamic type of the interface. And since it
> can't override methods, there is no path-dependence - any two methods sets
> uniquely determine a maximal common subset and a minimum common superset
> and the path from any interface type to any other interface is unique
> (structural subtyping is a Lattice
> <https://en.wikipedia.org/wiki/Lattice_(order)>).
>
> I think any kind of subtyping relationship *should* ultimately allow you
> to have multiple super types - these kinds of hierarchies are just far too
> common to ignore. For example, look at the `io` package - pretty much every
> combination of `Reader`, `Writer` and `Closer` has some reasonable use
> cases. I also think there are good technical reasons to avoid the
> path-dependency pitfall. So it seems to me an easily defensible decision to
> use structural subtyping as the primary form of subtype relationship, as it
> allows you to have the benefits without the problems.
>
Structural subtyping has the most advantage in this use case, multiple
super types can be expressed with a new interface (and struct embedding as
needed) without changing anything in other packages, so it's not something
I'm going to question over again, and I do take some notes about the method
resolution issues and the insight about lattice above, thank you for the
pointer, I really appreciate it.
> We could do both (and disallow multiple inheritance 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 these hierarchies, e.g. some abstract
types to have `From` and `Into` construct a la Rust.
>
> On Fri, Oct 20, 2023 at 8:07 AM Bakul Shah <ba...@iitbombay.org> wrote:
>
>> On Oct 19, 2023, at 9:02 PM, Nurahmadie Nurahmadie <nurahma...@gmail.com>
>> wrote:
>> >
>> > Is it not possible to have both _auto_ downcasting and new method
>> binding to work in Go?
>>
>> What you are suggesting may make things more *convenient* but
>> at the same time the potential for accidental mistakes goes
>> up. The key is find a happy medium. Not too much discipline,
>> not too much freedom!
>>
>>
>> --
>> 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/BB7C6A9A-F0BE-4180-B495-93E4B195EA97%40iitbombay.org
>> .
>>
> --
> 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/CAEkBMfHRZLhxCM%2BMRNK7san%3D_%3DSgRF79QfZgKhu1%3Df1twWdSRw%40mail.gmail.com
> <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHRZLhxCM%2BMRNK7san%3D_%3DSgRF79QfZgKhu1%3Df1twWdSRw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
regards,
Nurahmadie
--
--
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/CA%2BcQEWGNFqsfj_oDunswo8rwVOi-N88roVMxzqC9UH_kfSyxmA%40mail.gmail.com.
