On Tue, May 3, 2022 at 12:28 PM Changkun Ou <m...@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/CAOyqgcW_AnnZbRoUVBH5tK_NzN4Paq%3D_p-BUXcb-Q33mYDamYw%40mail.gmail.com.
