Hi Axel and Ian,
Thanks for the elaborative answer! I was too naive while considering the
case and didn't observe the existing practices well. Assignability seems to
create a lot more complicated compatibility issues.
Regarding the compatibility promises to users, it always seems the
interpretation of developers and users is less effective in this area. I
wonder what might be a possible way to involve a successful impact here. Is
there any old practice that exists? Especially in the Go project itself :)
Also, the fantastic talk by Jonathan illustrates and saves me potentially a
lot of time from a very early attempt to tackle the problem once again.
Changkun
On Tuesday, May 3, 2022 at 9:38:35 PM UTC+2 Ian Lance Taylor wrote:
> On Tue, May 3, 2022 at 12:28 PM Changkun Ou <ma...@changkun.de> wrote:
> >
> > I wonder how the Go project defines a breaking change, specifically for
> the case where we have an existing API but want to add ... to its parameter
> list for customizations.
> >
> > For instance, we have an API:
> >
> > package foo
> > func Bar() {}
> >
> > And the current code uses this function as:
> >
> > foo.Bar()
> >
> > Now, we added a ... to the Bar() and having a new function signature:
> >
> > func Bar(args ...any) {}
> >
> > Technically, the language allows the existing users to continue to work:
> >
> > foo.Bar() // still OK.
> >
> > As long as we don't change how Bar() behaves by default, it seems that
> the code that previously used foo.Bar() is still considered valid and not
> breaking. Is introducing this type of API signature change considered a
> breaking change in the standard library?
> > What if we propose API changes like this to the existing standard
> library, will it be considered differently compared to an actual breaking
> change?
>
> In the standard library we would consider that a breaking change,
> because it would break code like
>
> var f = []func() { Bar }
>
> You might be interested in Jonathan Amsterdam's Gophercon talk:
> https://www.youtube.com/watch?v=JhdL5AkH-AQ
>
> 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/b4db9ee0-ee65-4f69-a51f-11ed736b43dan%40googlegroups.com.
